richard@chaos.cs.brandeis.edu (richard Congdon) (02/25/90)
Since it looked like it might be a better of of backing up, I thought I'd try fbackup instead of dump. So, I kicked it in on my 9000/850 (3.1) at level 0 and waited for the tape drive to start moving. And waited. Three hours later it is still doing something (collecting file names, I think. As this was going on, I watched the data size grow to about 15M). I killed it, and started again. Same thing. Is there something I'm missing here, or do I have a bad program, or is fbackup just not a good way to do this? -- Richard Congdon Brandeis Computer Science richard@chaos.cs.brandeis.edu 617/736-2717
paul@prcrs.UUCP (Paul Hite) (02/28/90)
In article <1990Feb24.214030.4541@chaos.cs.brandeis.edu>, richard@chaos.cs.brandeis.edu (richard Congdon) 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. The increase in process size that you noted is normal for fbackup. It builds a list of all files to backup in virtual memory before it does anything else. fbackup and its children, /etc/fbackuprdr and /etc/fbackupwrtr communicate with each other via shared memory (as well as pipes and even a semaphore) which adds to vm requirements. We can live with the resource hogging. The real bad news is that trying to restore a file can be a real nightmare. In the worst case, I have spent 3 weeks trying to restore a file. And that was with continual help from our SE. This was because fbackup had misordered the files on tape and frecover didn't believe that the file was on tape. I finally got the file by restoring the entire tape. Even when a file is successfully restored on the first try a few thousand messages like : frecover(1003): backup id does not match expected value frecover(1043): error in header on recover frecover(1003): backup id does not match expected value frecover(1043): error in header on recover are not uncommon. Somehow the restore seems to work anyway. fbackup interacts with the system in very unusual ways. Once, we a problem where fbackup would loop forever during it's startup phase. This was due a the following entry in our /etc/passwd file: nobody:Nologin:-2:-2:anonymous NFS user:/: It seems that fbackup can't handle a negative uid. Sometimes a problem with fbackup is not repeatable. Because it's a family of processes that may be scheduled differently with different attempts, it's hard to capture an example of some of the problems we see. If things get screwy, sometimes it will work when you simply retry it. fbackup is much too complex for the simple task it tries to perform. This needless complexity makes me suspect that fbackup is hopeless. I don't have much faith in our ability to restore files from from our backup tapes and I'm very sorry that I ever heard of fbackup. You mention that you currently use dump/restore. What do you think of them? dump/restore looks good as long as you use one tape per file system, but we have too many filesystems for that. The BSD dump has the length of the tape built into the program, does the HP version? We have a compressing tape drive but if dump doesn't know the true capacity of the tape then the compression won't do us much good. Paul Hite PRC Realty Systems McLean,Va uunet!prcrs!paul (703) 556-2243 DOS is a four letter word!
gentry@kcdev.UUCP (Art Gentry) (02/28/90)
In article <625@prcrs.UUCP> paul@prcrs.UUCP (Paul Hite) writes: >In article <1990Feb24.214030.4541@chaos.cs.brandeis.edu>, richard@chaos.cs.brandeis.edu (richard Congdon) writes: >> >> Since it looked like it might be a better of of backing up, I >> thought I'd try fbackup instead of dump. > > [sad story about the affairs of using fbackup deleted for brevity] > >fbackup is much too complex for the simple task it tries to perform. This >needless complexity makes me suspect that fbackup is hopeless. I don't have >much faith in our ability to restore files from from our backup tapes and I'm >very sorry that I ever heard of fbackup. I have to agree whole heartily! That is the reason I wrote my own backup scripts. Basicly, on a per file system basis, I find all the files, sort the list and feed it to cpio and update a file that shows when the last dump was made. Amoung other things, it makes restorals about as painless as possible, I can easily and quickly restore any single file, directory of files or an entire file system. I do this once a week. Every evening, run by cron, I have another script that goes out and finds every file that has been added/modified in the previous 24 hours and dumps them to tape in cpio format, again, very easy to do restores from. I am a firm believer in the KISS principle, why frecover/fbackup is so damn comlex is totally beyond me! >You mention that you currently use dump/restore. What do you think of them? >dump/restore looks good as long as you use one tape per file system, but we >have too many filesystems for that. The BSD dump has the length of the tape >built into the program, does the HP version? We have a compressing tape drive >but if dump doesn't know the true capacity of the tape then the compression >won't do us much good. You could use my same process and save multiple file systems to a single tape. I do one file system/one tape, just to keep things a little simpler. These scripts are available on the Interex (HP International Users Group) Contributed Software Library tape, avaliable from Interex, 585 Maude Ct. Sunnyvale, CA 94088 (408) 738-4848. -- | R. Arthur Gentry AT&T Communications Kansas City, MO 64106 | | Email: gentry@kcdev ATTMail: attmail!kc4rtm!gentry | | The UNIX BBS: 816-221-0475 The Bedroom BBS: 816-637-4183 | | $include {std_disclaimer.h} "I will make a quess" - Spock - STIV |
burzio@mmlai.UUCP (Tony Burzio) (03/01/90)
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 * *********************************************************************