FBACKUP CONFIG

[Nobody's Hero]

Hi All,

Starting to use a config file for all of our fbackup processes. I have some timing issues with some open files during backup. I am going to set maxretries to '5'. Does anyone know what the default value for this field is, if I didn't specify a value? Also, does nyone have a good example of a config file. We mostly backup up root, /app areas, and an oracle export area to DLT and DDS.



Thanks,
RPM

[Steve Steel]

Hi


From man page


blocksperrecord 16
records 16
checkpointfreq 256
readerprocesses 2 (maximum of 6)
maxretries 5
retrylimit 5000000
maxvoluses 100
chgvol /var/adm/fbackupfiles/chgvol
error /var/adm/fbackupfiles/error
filesperfsm 200

Each value listed is also the default value, except
chgvol and error, which default to null values.


This is good for most systems . If you have problems put maxretries on 2 (it wastes tape space) and filesperfsm and readers up


Steve steel

[James R. Ferguson · Accepted solution]

Hi Robert:

The default value for 'maxretries' is five (5). See the man pages for 'fbackup' for this information and the other parameter's defaults.

Remember that every file retry means wasted time and wasted tape. When 'fbackup' starts to transfer a file from disk to tape it notes the timestamp of the file on disk. When the transfer to tape has completed, 'fbackup' examines the timestamp again. If it has changed, the tape copy is marked "bad" and a new copy (from disk) is started again for the file in question. This process will be repeated until a static timestamp is seen or have been exahusted. The default is five tries. The problem is that tape is consumed for each copy transferred. During a subsequent 'frecover', the bad copies of the file must be traversed and skipped.

The default values for 'fbackup's configuration file are archaic. They provide very poor performance for backup and for potential recovery.

A good set of values look something like this:

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

Note that the 'readerprocesses' default is two (2), but six (6) are allowed. The higher the number the more concurrent processes read data to deliver to the tape. Too low a number may result in the tape drive falling in and out of streaming mode thereby reducing copy times significantly.

For more , an excellent document is #KB00000196 "Understanding Fbackup/Frecover and Optimizing Backup Performance" (attached for your convenience).

Regards!

...JRF...

[James R. Ferguson]

Hi (again) Robert:

Sorry, that document ID should be: KBRC00000196.

Regards!

...JRF...

[Nobody's Hero]

Thanks James,

Very interesting. So in a nut shell, if you have an open file that is trying to get backed up. Your backup is sort of in a wait state until either the timestamp has not changed or the max retries has expired. Is that correct. So you loose vlauable backup time wile it retries this one file only?

[Nobody's Hero]

James,
Another question.

You said " During subsequesnt 'frecover', the bad copies of the file must be traversed or skipped." I encounter this problem very often where there is a busy file on tape so it was skipped on the backup. When I try to frecover a file past that point I can't get to it. It just sits and sits and sits. How can you traverse past that file that is bad?

[James R. Ferguson]

Hi Robert:

As I indicated, 'fbackup' notes the timestamp of a file as it begins to transfer it from disk to tape. When the transfer finishes, the timestamp of the file on disk is compared to the timestamp value that existed when the transfer began. If they are different, the tape copy is marked "bad". 'frecover' will not copy this data from tape to disk.

Thus, yes, you waste time (and tape!) recopying a file that is changing.

Files on the tape that were successful copies, even if they are downstream of a "bad" copy are extractable by 'frecover'. My point is that to reach them, the tape has to be read, and if that means reading extra copies of files, that's time (and tape) that is wasted (again).

Regards!

...JRF...

[Nobody's Hero]

Thanks James,

Good explination and link. I always wondered what the devices were actually doing during an encounter such as this.

Thanks again.

[Simon_6]

Hi James,

I find your message very helpful, however, I am having problem finding the document "Understanding Fbackup/Frecover and Optimizing Backup Performance". Could you send me the web link to it. Thanks.

Simon