🚀 go-pugleaf

We here have workstations and servers from  DEC, Sun, SGI, 
HP and IBM.  Our network backups, running for more than 2 years now, are
taken on an Epoch Systems server; this has the [huge!] advantage of 
built in volume management [the backup program doesn't do it, the 
system volume manager does], database support, and support for file
migration from magnetic to optical disks.

The solution we run currently is simple and script based: the Epoch mounts
(NFS) other servers or workstations on our net, and runs the Epoch
backup program on these filesystems, to Epoch's 8mm (5GB) tapes.  The
index files are all in the Epoch's database, and are also backed up and
migrated on the Epoch.  This Epoch (an Epoch-1) has two Exabyte 10i
robotic units, so most tape handling is automated (we try to keep
recent backups in the 10i's, for recoveries, but also make sure some
"available" tapes are in them for the night's backups).  We have
*never* lost a file (or a single byte as far as we can tell) with this
scheme.  The only flaws we have seen are: (1) our scripts need to be
more robust; (2) the backups are not fast enough; (3) recovery is not
fast enough; (4) only the Epoch's administrator can recover files. 
Of course, the scheme is somewhat ad hoc....

Epoch announced a new product in April, called "Renaissance Backup Service".
(We are a beta site, but I can talk a bit about it....)
With this product, some software (not much it turns out) is installed on
each "client" system (system whose files are to be backed up), but the
Epoch server is the controller and storage manager for the backups.
Multiple (up to 24 in the current implementation, I believe, with
something like 64 ultimately; of course, some more reasonable number will
probably be all you'd want to use) client data streams can come to the
server simultaneously, and can be sent to multiple tapes.  All the indexing
is handled automatically, and is all stored on the Epoch; the index files
are all under the migration system's control, so very large indices are
possible, allowing quite large nets to be backed up, and indexed, and
recovery to be fast (remember, the 10i's are there, so tapes for recovery
can often just be automatically accessed via the system volume manager), 
even for relatively old backups.  

The configuration is all controlled on the Epoch server from a single file,
which lists the valid users (who are the backup admins? who can recover
whose files to where?), the valid client hosts, "work-groups" of 
"work-items" -- which are specifications of files to backup on some client
(a client can have multiple work-items; typically, one filesystem per
work-item is appropriate, but you can be more or less granular than that)
using an extended "find" syntax, backup "trailsets" -- which define 
pools of media (with automatic management of alternate media if desired, to
generate a coherent backup set for offsite storage), and backup "templates" --
which associate work-groups with trailsets, define retention times, and
some other characteristics.  You can assign different media "trails" (sets
of media) to the different backup templates down to each different backup
level (0-9, a la dump).  

One real nice piece of this is the automatic scheduling; if your favored backup
scheme is: get a full (0) backup once per <time-period> of all the files
in some set of work-groups, and every other day get a level 9 (for this
program, a true incremental from the last backup of any sort), then you
just tell the backup template for that group to automatically schedule.
You tell the program how long to work each night, how much net bandwidth
to consume, and how many simultaneous full or incrementals to write to 
tape, and it figures out a "load balance" (which obviously gets better with
time) to do this.  You don't have to worry about it at all.

This seems to work pretty well so far; it is only beta right now, and
does require an Epoch-1 (although the Epoch-2, just introduced in April
also, are just repackaged Sparcs, with SunOS + Epoch management
software will support RBS soon I'm told), so may not be appropriate
everywhere.  Fast recoveries, fast backups, users can recover their own
files (the GUI is not out yet, but is coming, I'm told) (if the admins
let them!), and it seems to be *very* robust -- lots of error checking
and logging, if you want.

We think it's great!  We were able to rebuild a crashed system (Ultrix)
disk across the net in about an hour (about 290 MB all together), from
files scattered over about 7 tapes.  Not bad.  We've recovered some
other filesystems, single files, directories, etc., all quite quickly.
The management of the server is also fairly straightforward.
(After installation, there is really nothing to do on the clients.)

We plan to run Zwicky's "torture-test" on RBS, and I'll let y'all know
how that works.  Has anyone tried it with DECnsr or vanilla Legato Networker
or the SGI version?  Epoch tells me that they ran similar tests on RBS, 
but this specific test.  They *do* deal with files with holes well (actually,
they are if anything overly aggressive about them!), and do seem to handle
pretty long names ok, but we haven't yet subjected it to truly anomalous
files/names.  I expect it'll work fine.

Just another view....


Steve

---
Steve Couturie                      Voice:     (310) 694-9332	
Chevron Information Technology Co.  FAX:       (310) 694-7709
P.O. Box  446                       Internet:  shc@chevron.com
La Habra, CA  90633-0446            UUCP:      ...!uunet!lhdsy1!shc