[88] in Back_Bay_LISA
October BBlisa Notes (finally)
daemon@ATHENA.MIT.EDU (John_Rouillard@dl5000.bc.edu)
Sun Nov 22 16:26:03 1992
From: John_Rouillard@dl5000.bc.edu
Date: Sun, 22 Nov 92 14:39:27 EDT
To: bblisa@inset.com
Hi all:
These are my notes from the October Back Bay LISA presentations, and
some of the discussion afterwards. I apologize for the lateness, and
sketchiness of the notes. Hopefully this will give the people who were
not there a feeling for the issues brought up.
I have arranged the summaries from least polished to most polished.
At thee end of each summary, I have a checklist like the one below
that may be of some help in summarizing each system. After each item
is a reason its important, or a better explanation of the item.
Presenters please check the checklist at the end of your sections. If
you feel I have made a mistake, please let me know so I can correct it.
Tape Management:
Uses tape labels? (Prevents accidental destruction of tapes)
Maintains usage stats on tapes? (allows expiration of old tapes)
Supports multiple save sets/tape? (Efficient tape usage)
Supports multiple tapes/dump? (Eliminates need to "size" dumps to tape)
Provides support for offsite storage? (Safety/security in offsite storage)
Dump Support:
Tracks what is dumped to tape? (makes restores a lot easier)
Supports multiple levels of dump? (incremental take less time to run)
Supports multiple devices?
Provides dump coverage tools? (Make sure everything is being backed up)
Provides dump scheduling tools? (Make admin's life easier)
Operates in parallel? (speed up the dumps)
Applicability:
Supports non-unix systems? (Hey, its not just a Unix world out there)
Ports to many Unix systems? (well, which obscure *ix OS are you running)
Restores:
Can restore disk exactly? (Nothing like overfilling a disk half way
though your first of 3 incremental)
Has automated restore tools? (Help facilitate operator restores of files for users)
Supports user initiated restores? (Helpful to stop users from pestering
your operators, also provides timely
service for you users)
Misc.
Support multiple programs? (Does is support gnu tar, dump, and cpio?)
Available for free? (Hey we all have budgets, but don't forget the
implicit cost of your time in installing and running
the system)
Professional support available? (The purchase money may be money well spent)
Available from? (FTP site, or author, or company)
Douglas Alan (nessus@mit.edu)
-----------------------------
Doug's talk was titled "How to Reliably Backup up to 50 Gigabytes of
Disk Space On One $3,000 Tape Drive, Using No Expensive Software, and
15 Minutes a Day". One of the items that was brought up was the need
to use magnetic tape labels to allow the software to (attempt to)
prevent inappropriate reuse of tapes. One of the other points brought
up was saving the software that was used to dump the tape on the tape
in an agreed upon format. Also these should be some means of
determining what is on which tape without having to read the tapes.
This last point becomes extremely important in the case of
non-homogenous dump mechanisms. For example, restore can not read a
GNU tar dump, nor can GNU tar read a BSD dump image.
Many of the other ideas he brought up are incorporated into the
software that was presented by others at the meeting.
This is sort of a discussion matrix since there is really no set
software for this talk.
Tape Management:
Uses tape labels? Yes
Maintains usage stats on tapes? No
Supports multiple save sets/tape? Yes
Supports multiple tapes/dump? ??
Provides support for offsite storage? No
Dump Support:
Tracks what is dumped to tape? Yes
Supports multiple levels of dump? Yes
Supports multiple devices? Yes
Provides dump coverage tools? No
Provides dump scheduling tools? No
Operates in parallel? No
Applicability:
Supports non-unix systems? Possible (via NFS mounts).
Ports to many Unix systems? Yes.
Restores:
Has automated restore tools? No
Can restore disk exactly? Yes (using dump/Gnu tar)
Supports user intiated restores? No.
Misc.
Support multiple programs? Yes
Available for free? NA
Professional support available? Yes, you are a professional aren't you?
Michael I. Bushnell (mib@gnu.ai.mit.edu)
----------------------------------------
Michael is the maintainer of GNU tar, which is designed to make
backups fun and easy. Well, I don't know about fun, but Gnu tar is a
big advancement over using a regular tar for backups. It has the
ability to fully reconstruct filesystems including deletion of files.
The current dump scripts provided with gnu tar don't provide for tape
labels, and have only one level of incremental built into them.
However, extending the shell scripts to support additional dump levels
seems relatively straight forward.
Also, multiple -f options can be specified, and tar will automatically
cascade from one device to the other when a device becomes full.
There is one bug with the current GNU tar version. The option that
resets the access time in the inode also resets the ctime which gnu
tar uses to determine if a file should be dumps. So the mere act of
dumping a file using the --atime-preserve guarantees that it will be
on the following night's dump. Michael is working on a mechanism that
dumps the data directly from the raw device when --atime-preserve is
used. So while the filesystem tree will still be scanned at the file
level, allowing pruning of what gets dumped, the data for files that
are getting dumped, will be read from the raw device as dump does,
thus bypassing the code that updates the atime field in the files
inode.
I see gtar as an element in a dump system as opposed to a dump system
in itself. The current scripts lack any sort of tape management. As
was noted above, tape labels are also missing. However, the GNU tar
program does provide a hook for an external program to be run when the
tape runs out. The current version of GNU tar is 1.11.1 and is
available from many archive sites.
Tape Management:
Uses tape labels? No.
Maintains usage stats on tapes? No
Supports multiple save sets/tape? Yes
Supports multiple tapes/dump? Yes
Provides support for offsite storage? No
Dump Support:
Tracks what is dumped to tape? No
Supports multiple levels of dump? Yes (needs work for more than 1 level).
Supports multiple devices? Yes
Provides dump coverage tools? No
Provides dump scheduling tools? No
Operates in parallel? No
Applicability:
Supports non-unix systems? Yes (via NFS mounts), ports
are available for DOS and other systems
Ports to many Unix systems? Yes.
Restores:
Has automated restore tools? No
Can restore disk exactly? Yes
Supports user intiated restores? No
Misc.
Support multiple programs? No
Available for free? Yes
Professional support available? No
Available from? better archive sites everywhere.
Adam Moskowitz (adamm@inset.com)
--------------------------------
Well, I can't do as good a summary as the author, so I'll let him suummarize.
> Our system is designed to handle several small workstations using only
> one tape drive. The system is written mostly in sh, with a few small C
> programs to support it. As a result, it can easily be modified to handle
> WORM drives, carousels, or juke boxes instead of tape drives. The system
> runs on UNIX, but by using NFS it can handle non-UNIX systems; it also
> makes use of as many CPUs as it can, doing operations in parallel where
> possible. For example, the list of files to be saved is done this way.
> Like the system from OSU, and following the suggestions made by Douglas
> Alan in his talk, our system checks tape labels before writing to them,
> keeps track of what was written to each tape and when, and sends error
> via e-mail (actually, it send the output of each night's run). The
> system currently uses GNU cpio, but after hearing Michael Bushell's talk
> about GNU tar, I may switch.
>
> The software will be available, via either e-mail or FTP, as soon as it's
> finished and packaged; I expect this to be sometime early next year
> (January, schedules permitting). Send mail to adamm@inset.com in January
> if you're interested.
Adam's set of programs has some rather unique features. Since Adam's
program is based on a using find and GNU cpio, generating the list of
files, and eliminating the files that shouldn't be dumped takes a lot
of time. This is done in parallel on all of the machine, and the
master control script notifies each machine when it can access the
tape drive, and actually dump its files to tape. Thus it does some
parallel operation without neededing intermediate filestorage.
Also, the mechanism for determining what the dump level is is also
rather interesting. The label that is on each tape determines the
level of the dump. This allows easy operation by untrained people.
Just pop the right tape into the drive, and the level etc. are already
established.
Tape Management:
Uses tape labels? Yes
Maintains usage stats on tapes? No
Supports multiple save sets/tape? Yes
Supports multiple tapes/dump? No
Provides support for offsite storage? No
Dump Support:
Tracks what is dumped to tape? Yes
Supports multiple levels of dump? Yes
Supports multiple devices? Can be extended
Provides dump coverage tools? No
Provides dump scheduling tools? No
Operates in parallel? Yes
Applicability:
Supports non-unix systems? Yes (via NFS mounts)
Ports to many Unix systems? Yes.
Restores:
Has automated restore tools? No
Can restore disk exactly? No, but yes with gnu tar.
Supports user intiated restores? No
Misc.
Support multiple programs? No
Available for free? Yes
Professional support available? No
Available from? Its author in January
John Rouillard (rouilj@ra.cs.umb.edu)
-------------------------------------
The OSU-CIS backup system was originally presented as part of the LISA
IV conference. One advantage of the system is that it can use the
native backup and restore tools that were supplied with the system.
Currently modules have been written for Ultrix, and BSD type dumps, as
well as GNU tar. Modules for Fbackup, and Frestore should be available
in the future. In addition, modules using cpio, or some other dump
program could be easily integrated into the system.
The dump system runs on a number of machines, however in the current
release, the database must be accessible via NFS. With the current
alpha release of the software, all database accesses have been put
into a single module, so that writing a database module that does
database access via remote commands, or TCP socket connections is
feasible. Also, because the database uses perl's DBM access
functions, there is a byte order issue to contend with as well. For
those of us who use different byte ordered libraries, we have created
a perl linked against a byte order independent database (the 4.4 bsd db
library) that works very well.
The main program "all-backups" is responsible for determining what tape
should be loaded, and the electronic label on the tape is checked
before any destructive operations are done to the tape. Since multiple
savesets may be on a single tape, the backup system records the
location for each saveset on the tape. This information is used by the
"getback" program to find the proper files when doing restores, or it
can be printed off in hardcopy for hand restores.
There are too many features in the system to list them all, but here
are some that have come in handy:
o Supports running a program before dumping a filesystem (say to tun off
running daemon on the filesystem)
o Supports checking to see if the proper tape is in the tape drive,
and warning the staff if this is not the case. This allows a
dump to be scheduled for 1AM, but the check to occur at 10PM before
the last operator goes home in case a restore or something required
removing the tape from the drive after it was scheduled.
o Supports dumping a machine in single user mode.
o Provides a simple tags capability to allow dumping of only some
of the filesystems on a host in a given run.
o Provides support for offsite tape storage. Will schedule/remind
user to take tapes offsite.
o Provides support for multiple backup sites each with its own tape pool,
and backup devices.
o Provides for dumps to tape, and/or disk. Parallel dumps can be done to
intermediate disk. Then the dump image is transferred to tape if
necessary.
Since there can be a number of different backup programs used in the
system, the exact features that are supported vary depending on the
backup program.
Tape Management:
Uses tape labels? Yes
Maintains usage stats on tapes? Yes
Supports multiple save sets/tape? Yes
Supports multiple tapes/dump? Soon (GNU tar only)
Provides support for offsite storage? Yes
Dump Support:
Tracks what is dumped to tape? Yes
Supports multiple levels of dump? Yes
Supports multiple devices? Yes
Provides dump coverage tools? Yes
Provides dump scheduling tools? No, but some are in the works
Operates in parallel? Yes (with intermediate disk storage
for compressed dump to go to)
Applicability:
Supports non-unix systems? Yes (via NFS mounts)
Ports to many Unix systems? Yes, but may require a rebuilt perl
if native databases are used.
Restores:
Has automated restore tools? Yes
Can restore disk exactly? Yes
Supports user intiated restores? Soon, with gnu tar only
Misc.
Support multiple programs? Yes
Available for free? Yes
Professional support available? No, but a mailing list does exist.
Available from? ftp.osu-cis.edu:/pub:
Steve Glassman (glassman@epoch.com)
-----------------------------------
The Epoch system has a number of features that seem invaluable when
dealing with many hosts:
o A dump scheduling tools to make sure that all
systems are covered, and automatically scheduled.
o Support for multiple savesets/tape, and multiple tapes/saveset.
o Provides a secure front end for users performing their own
restores. Indeed Epoch is the only system that does provide
for user level restores.
o "True Incremental" dumps. This type of dump records
everything from the last dump AT that level or lower, as
opposed to regular incremental where everything from the
level LOWER than (i.e. not equal to) the current level
is dumped. This allows the sizes of incremental dumps to
remain relatively constant.
The backup software is linked to Epoch's EpochServ system.
The EpochServ system actually handles the tape management issues,
unlike the previous backup systems that handle the tape management
internally. Also, the data on the tapes is written in a proprietary
format to allow for a speed increase. There is a possibility of a
stand alone tape reader being developed, so that the tapes can be read
even if most of the network is down, or in case of a catastrophic
failure.
Also, this system isn't free. However, given that this is a commercial
product, it may well be worth the money to purchase the system as
opposed to the money that is implicitly spent in installing and
maintaining a home grown, or network obtained package.
Tape Management:
Uses tape labels? Yes (EpochServer's job)
Maintains usage stats on tapes? Yes (EpochServer's job)
Supports multiple save sets/tape? Yes (EpochServer's job)
Supports multiple tapes/dump? Yes (EpochServer's job)
Provides support for offsite storage? Yes
Dump Support:
Tracks what is dumped to tape? Yes
Supports multiple levels of dump? Yes
Supports multiple devices? Yes
Provides dump coverage tools? Yes
Provides dump scheduling tools? Yes
Operates in parallel? Yes (also multiplexes data onto tapes)
Applicability:
Supports non-unix systems? ??
Ports to many Unix systems? Yes, but you won't be able to do it.
Restores:
Has automated restore tools? Yes
Can restore disk exactly? Yes
Supports user intiated restores? Yes
Misc.
Support multiple programs? No uses own format.
Available for free? Yes
Professional support available? Yes
Available from? Epoch Systems (508) 836-4300
=====================
After the presentations one of the questions that was asked dealt with
using 8mm video cassetes for backups. Steve Harris from Eaton Corp
reminded me that one of the gentlemen from Epoch Systems didn't
believe using 8mm video cassetes was a good idea.
He said that that exabyte tape degradation does not normally result
in failure, just repeated retries and repeated marking of blocks as
bad. The net result is that your backups take longer and longer to
complete.
Also, AdamM had some additional comments:
Well, the biggest difference between Epoch and everything else is that
theirs cost money. Big money. Also, their system is the least portable of
all. As for comparisons to GNU tar, well, I think that's more a building
block to be used by folks like you & me & Douglas rather than a complete
system.
As for sh v. perl: For one thing, perl is Yet another Language to be
learned, and I've got precious little time to do that as well as a brain
that's starting to over-flow with stuff I *need* to keep in it. Then,
perl is not small, and while not hard to port, it's non-trivial. I've
avoided it for disk space reasons as much as anything else. Finally, I
still don't agree that there's an advantage to being able to do
everything in one language when 2 awk's with a sed between them (or the
reverse) will do most everything anyway. Last, I haven't yet met a
SysAdmin that *didn't* know sh, nor have I met one that didn't have more
than a passing familiarity with awk & sed!
--
Send mail for the `bblisa' mailing list to `bblisa@inset.com'.
Mail administrative requests to `bblisa-request@inset.com'.
