topic Re: fbackup in Operating System - HP-UX

fbackup

ICT Infrastructure — Mon, 23 Jun 2003 12:39:03 GMT

Hello,

Tonight for the first time I will be using fbackup to run a full root system archive. Previously I have used tar but I now have files > 2Gb.
I am planning to use the command;

fbackup -f /dev/rmt/1m -i / -I /tmp/index.lucy

Will it work? I am testing now on one of my test servers but it's slow slow, I'm not sure whether or not it will finish in time!
Every night I also run an application specific backup so that is safe!

Re: fbackup

James R. Ferguson — Mon, 23 Jun 2003 12:47:48 GMT

Hi:

If you are not using a 'config' file with 'fbackup' you are going to get very poor backup performance.

As documented in the man pages for 'fbackup' in the absence of an explicit configuration file ('-c config'), default values are provided. However, these defaults are archaic and will not yield decent performance with modern tapes and tape drives. A much better set of parameters look something like these:

blocksperrecord 256
records 32
checkpointfreq 1024
readerprocesses 6
maxretries 5
retrylimit 5000000
maxvoluses 200
filesperfsm 2000

These parameters are recorded onto the actual backup tape and are thus used for a 'frecover' session too.

Checkpoint records allow the salvage of a backup when a bad tape spot is detected, since the records contain information about the file being backed up. The 'filesperfsm' parameter controls the frequency with which Fast Search Marks (FSM) are written. Both checkpoint and FSM records affect performance. FSMs take a tape drive out of streaming mode thereby adding to backup time. Conversely, however, FSM???s improve the time it take to recover a file from tape.

In general, if your backup consists of a high proportion of small files, increase the value for 'filesperfsm'. If your backup consists of a high proportion of large files, then decrease the 'filesperfsm' value.

Regards!

...JRF...

Re: fbackup

Stefan Farrelly — Mon, 23 Jun 2003 12:47:52 GMT

fbackup has no 2GB limit so you can use it to backup files >2GB without problems.

Normally you should supply fbackup with a config file (-c option) which helps backup times and restore times. Heres a typical one we use;

blocksperrecord 128
records 32
checkpointfreq 256
readerprocesses 4
maxretries 1
retrylimit 0
maxvoluses 500

Try using one like this, it should help your backup speed a fair bit.

Re: fbackup

Michael Elleby III_1 — Mon, 23 Jun 2003 12:50:45 GMT

It can work, but there are 2 issues that stand out to me:

1. fbackup may kick out a lot of messages about files in use, because there will be files 'open' by root and other processes. This pretty much says that the file is not fully backed up.

2. How much data are you backing up hence, what type of tape drive/capacity are you backing up to? Fbackup will pause once the tape it is writing to is full.. To do a root system backup, I just do an Ignite of the system, which pretty much covers all of the critical system files that I need backed up.

Mike-

Re: fbackup

PIYUSH D. PATEL — Mon, 23 Jun 2003 12:52:08 GMT

As mentioned, i / means backup everything including NFS and even CDROMs! So for a general backup, you would exclude CDROM mountpoints and NFS mountpoints. fbackup reads the rules in sequential order so to backup "everything except" start with the include everything item, then exclude specific directories.

HTH,
Piyush

Re: fbackup

James R. Ferguson — Mon, 23 Jun 2003 12:58:31 GMT

Hi (again):

'fbackup' backup open files. When 'fbackup' begins to transfer a file from disk to tape, it notes the timestamp of the disk file. When the transfer of the disk image to tape completes, the timestamp is examined again. If it has changed, indicating a potential change in the file content, 'fbackup' will issue a warning message; mark the copy of the file on the tape as "bad" so that it cannot be recovered; and attempt to recopy the file. This recopy process will be attempted 'maxretries' times (as specified in the 'config' file for 'fbackup') or until the file can be successfully transferred to tape and remain unchanged on disk during the transfer.

One problem with the retry mechanism, as should be appparent from the above, is that time and tape are used. Thus retries can greatly slow down the overall backup time.

Regards!

...JRF...

Re: fbackup

Darren Prior — Mon, 23 Jun 2003 13:10:50 GMT

Hi,

If you're making this backup in case you need to rebuild a system after failure then it would be far better to use make_tape_recovery. This makes recovery much easier than installing part of the OS, then having to use frecover the correct bits back again.

regards,

Darren.