Path: utzoo!attcan!uunet!mmlai!burzio
From: burzio@mmlai.UUCP (Tony Burzio)
Newsgroups: comp.sys.hp
Subject: Re: fbackup
Summary: fbackup and Rip Van Winkle
Message-ID: <684@mmlai.UUCP>
Date: 1 Mar 90 14:49:38 GMT
References: <1990Feb24.214030.4541@chaos.cs.brandeis.edu> <625@prcrs.UUCP>
Organization: Martin Marietta Labs, Baltimore, MD
Lines: 25

In article <625@prcrs.UUCP>, paul@prcrs.UUCP (Paul Hite) writes:
> > Since it looked like it might be a better of of backing up, I
> > thought I'd try fbackup instead of dump. 
> 
> We have an 850 with an 8-pack of 7937's.  We do a full backup once a month.
> fbackup requires between 4 and 5 hours before it starts to write to tape.
> All told a monthly backup takes about 11 hours.  This is best case performance.
> During the 5 hour startup routine, fbackup requires about 90% of the cpu (as
> reported by LaserRX/UX).  Put some users on and things really get slow.

We have 3.5GB of disk drive on our HPs, with 1GB across the network.  Fbackup
is very quick for us, and can reliably restore files, <BUT> do NOT have it
obtain a list of files to be backed up before it starts!  This is what it
is doing at the start of your process.  If you just let it dump the files
to tape, then it will work just fine :-)  From what you say, it gets the
file list wrong anyway...  You can also "nice" the process to minimize impact
on your CPU, althought your network NFS backup clients will still be slagged
by fbackup (or anything else with heavy incoming NFS requests :-) since
NFS has priority over local processes.

*********************************************************************
Tony Burzio               * The South shall rise again!
Martin Marietta Labs      *  - and the North will be there to tax it! :-)
mmlai!burzio@uunet.uu.net *
*********************************************************************