Non-standardisation seems to be the rule when UNIX tape backup software and systems. Thus it looks like tape backup with UNIX is a pain as if lucky, when backing up with XFSDUMP (preferred option) only another SGI with IRIX 6.5.x can recover the tapes.
For archiving, non-compressed drives are used as even with compression, the web_disc will not fit on a single tape. So may as well minimise complications for disaster recovery by not having compression.
Commercial options exist but they seem more based on network backups rather than a local disk on a single server to a local tape drive.
EMAIL RECEIVED 7th SEPTEMBER 1999 > I've been going through your summary page on backup on SGI. >You say xfsdump is more suited to you than bru. > > Could you please comment on this? I'm setting up a backup system >using bru and sh scripts, and wonder why I should prefer xfsdump? >Is this due to problems of bru with long file-names, or recovery? > > Thanks for commenting on this Hi Jahor, I chose xfsdump after evaluating pretty much everything except bru and chose it before finding out about bru. However, when hearing about the problems bru had (long file name and directory problems making it sound very unattractive - and having a look through the man page on bru), I decided to stick with xfsdump as xfsdump does seem to work OK for me - and unlike the others I looked at - does not need to run deamons for local backups from harddisk to tape. I think it is the case of you use the first one that is found to work for you. So if bru is doing the job OK for your and not causing problems, you don't really have a reason to change. --- Again, I am doing local backups - though the scripts provided by Brent Bates were not specific to xfsdump and were network based. I would suggest trying out both xfsdump and bru - and see which works the best. I mainly was concentrating on recovering individual files onto a separate area as part of archive recovery. Though re-reading about bru again - superficially it does look OK. I guess I must have been scared off by the newsgroup not to take it seriously at the time. Lachlan.
Hardware and various device options that can be activated by writing to the device names in /dev/rmt
Summary: A script using xfsdump is used to do a full backup of the system (tapes stored on-site and off-site) followed by a daily level 1 incremental backup onto single tapes. During level 1 backup, iImportant files are "touched" so they will be retrivable from any level 1 tape.
XFSDUMP seems the most appropriate for backing a stand-alone system as other systems are made more for network backup and require deamons to be running that are not neccessary in this case.
The scripts are based on ones provided by Brent Bates - http://www.vigyan.com/~blbates/
Xfsdump silently misses files. Bug Number : 641606 Product : Performance Co-Pilot Fixed-in Release : 6.5.6 IRIX Release : 6.5.2m Category : software Classification : bug Priority : 2 Status : closed Date Opened : 10/09/98 Date Updated : 08/31/99 Summary : Xfsdump silently misses files. Description : If a file is modified while xfsdump is running, the dump can fail for that file. The file appears in the dump listing, but the file contents are not in the actual dump. No error is reported when this happens. Fix Information : This problem has been fixed in IRIX 6.5.6. Any file that existed all through the xfsdump run is now guaranteed to be in the dump. If a file is modified during the dump, some version of the file is included in the dump. Note that it is not possible for all xfsdump to accomodate all scenarios, such as destroy/recreate sequences. DISCLAIMER: The version with this fix may not have been released yet. It is a possibility although unusual that a bug fix may be backed-out from the version prior to release.