Fbackup, Tar, Dump

[Nalin Uduwawala]

Which is the best method on a HP-ux 10.20 running on hp9000 d330, with external 12gb dat drive using the same scsi channel that the disk drives use ?

I saw in the man pages that fbackup can give problems if the tape drive and disk drives (that are being backed up) are on the same scsi channel.

any help advice would be appreciated.
Thanks in advance.

[Brian M. Fisher]

I believe the best backup solution for you would be to use fbackup on HP-UX. The advantages are:
1) Can configure backups via SAM
2) Backups can span tapes
3) The ability to do incremental backups
4) Allows remote tape drives
5) Reasonably fast

Brian
<*(((>< er

[Martin Geil]

I agree that fbackup is the best backup solution for you. I have used it extensively, with the tape drive both on and off the SCSI channel of the disks being backed up, and have not experienced any problems. The 12GB DDS-3 drives do a good job of buffering, and since their data rate is probably no better than 2MB/s including compression, you shouldn't get a noticeable bus contention effect.
However, fbackup's default configurable parameters may not be optimal, depending on the average size of your files and desire to speed up recovery at the expense of backup speed/capacity (or vice-versa). I typically modify the following parameters using a config file (-c option to fbackup):

blocksperrecord 128
records 64
checkpointfreq 1024
readerprocesses 2
filesperfsm 1000

(note that filesperfsm is the one that makes a big difference in file restore speed if you are not restoring the whole backup. Bigger ~= slower recovery/more data per tape/slightly quicker backups. I would suggest you test backups with the default parameters, then run them again with the above to see if you get a big enough difference to bother with.)

I would add that you should really use Ignite-UX to make a recovery tape for your system. This will greatly simplify things should you be so unfortunate as to suffer a problem with your boot disk.

[Nalin Uduwawala]

Thank you.

In fact I was considering the use of a config file. I will use your values.

I am using fbackup now and one directory constantly gives me the error (on frecover -Nvxf) active / unrecoverable error.

Now this when fbackupp this drive along with others. When I do this drive all on it's own under the very same conditions, then the backup happens fine !!!!!!!!!!!!!!!!!!.

The file s being backed up are not huge to overrun the tape.

My concerns with fbackup arose as a result of this strange UFO like behaviour.

Thanks again for the detailed reply .Please let me have your thoughts on this.

[Duane Gorder]

Before switching to Veritas NetBackup we used dump, or vxdump for vxfs file systems. There were two reasons for this: One, we have several different UNIX platforms to maintain, so using dump across all platforms made things more consistent. Second, the interactive restore for dump files is an incredible tool. However, dump only backs up individual file systems, each file system requiring a separate command. fbackup offers more flexibility there. Also, HP experts have always recommended fbackup whenever we have asked about backups.

tar and cpio are excellent tools for small amounts of data, but they are not recommended for large-scale backups.

[Martin Geil]

I'm afraid I would need more information to diagnose the problem you are having with verifying the backup of a particular directory. However, here are some general pointers:

1) Check that you have the latest fbackup/frecover patch installed, or the most recent one whose issues apply to your machines.

2) use the -i option of fbackup to create an on-disk index of your backup. The index file on the front of the tape is only what fbackup INTENDS to backup. The index file is created AFTER the backup completes, and is a record of what has actually been backed up. BTW, gzip will compress it by a factor of at least 10 if you want to keep a few lying around.

3) if you have a specific failure scenario, attach the command-line being executed, any unusual error messages in their entirety, and any supporting information (bdf, swapinfo, ll, etc...) that might be pertinent. Sometimes a seemingly innocuous bit of information provides the key.