Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!prcrs!paul From: paul@prcrs.UUCP (Paul Hite) Newsgroups: comp.sys.hp Subject: Re: fbackup Summary: Be afraid! Be *very* afraid! Message-ID: <625@prcrs.UUCP> Date: 27 Feb 90 18:11:17 GMT References: <1990Feb24.214030.4541@chaos.cs.brandeis.edu> Organization: PRC Realty Systems, McLean, VA Lines: 59 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!