Question about speed of fbackup to recover a file

[Randy Hagedorn]

Hi,

Is there a way to reduce the time it takes to recover a file from a fbackup backup tape? It appears that recovering a file takes almost as long (if not longer) to retrieve a file as it did to backup the files in the first place

Is this a typical characteristic of fbackup?

Thanks in advance,
Huggy

[A. Clay Stephenson]

This depends. If you set the checkpoint frequency very high then frecover can't do a fast seek to the segment which contains your file. Because fbackup uses multiple readers, it is possible that an extremely large file might have been backing up while thousands of small files were also being processed; in that case, the restore of a single file could take almost as long as a restore of all files.

In the typical case, however, frestore of a single file works fairly quickly. If you want truly quick point-and-click restores, you should look into OmniBack (or as it's now known DataProtector).

[Bill Hassell]

One of the most important features of frecover is the ability to perform high speed restores (not possible with classic Unix tools). HOWEVER, the technique requires a local tape drive (DDS or DLT) that can record the setmarks. Nothing is recorded if the tape is remote on another system, and yes, it will take a very long time.

frecover typically recovers a file at the end of a DDS3 tape in less than 5-10 mins.

[Randy Hagedorn]

Thanks Clay and Bill,

Our fbackup backup takes about 2.5 hours to complete. We tried to frecover a file from this tape and it took over 2.0 hours to accomplish. This is a local DDS-3 internal tape drive and this is what the fbackup script and frecover script looks llike.

/usr/sbin/fbackup -v -y -f /dev/rmt/0m -g /usr/local/bin/backup/fullbackup.graph

/usr/sbin/frecover -x -y -v -f /dev/rmt/0m -g /usr/local/bin/restore/restore.gra
ph

Does anyone see anything that would impede our frecover?

Thanks again.
Dewy

[Stefan Farrelly]

To restore an fbackup file as quickly as Bill pointed out you need an fbackup config file similar to the one we use on all our servers;

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

Then use the -c option on fbackup and now your restores should be much quicker.

[harry d brown jr]

Huggy,

Typically, a restore takes longer than a backup. A backup just reads the data and streams it to tape. A restore needs to deal with everything! If you are doing a lot of restores all of the time, I'd suggest getting more disk and staging the most current backups there.

live free or die
harry

[James R. Ferguson · Accepted solution]

Hi:

From the command syntax you have provided, it is clear that you are using 'fbackup's default configuration parameters. In the absence of an explicit configuration file ('-c config'), default values are provided for the 'fbackup' (and any subsequent 'frecover' session. See the 'fbackup' man pages). These defaults are archaic and do not provide good performance. A better set of parameters look something like these:

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

It is important to note that these parameters are recorded onto the actual backup tape and are thus used for a 'frecover' session.

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. As already noted 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...