Operating System - HP-UX
1748223 Members
4634 Online
108759 Solutions
New Discussion юеВ

frecover taking days to retrieve a file

 
Randy Hagedorn
Regular Advisor

frecover taking days to retrieve a file

I have a frecover job that has now taken over 2 days (still running) to retrieve a file. The fbackup was made on a production system with a DLT7000 and is being frecover'ed on a DLT7000 on a test system. The tape contains about 5-10% small files and the rest are multi-Gigabyte ORACLE RMAN files, one of which I am trying to retrieve.

I have observed that the activity light quickly blinks about once per two seconds.

Does anyone have any ideas why it is taking soooooooo long?

Thanks,
Randy
3 REPLIES 3
James R. Ferguson
Acclaimed Contributor

Re: frecover taking days to retrieve a file

Hi Randy:

There are a couple of reasons that immediatly spring to mind.

If any of your files were changing during the time they were being copied, then 'fbackup' wrote more than one (up to 'maxretries' copies) onto the tape.

When 'fbackup' transfers a file from disk to tape it notes the checksum of the file. At the conclusion of the transfer, the checksum is computed again. If it differs, the copy of the file on the tape is marked "bad" so that it cannot be recovered later with 'frecover'. This retry mechanism consumes tape and proportionally lengthens both the backup and recovery time.

Backing up sparse files (very common in databases) without compression will cause a vast amount of media to be consumed (again, both at backup and at recovery time).

Unless you have modified the default parameters in the configuration file used with 'fbackup' you are probably going to see very poor performance. The manpages for 'fbackup(1M)' document the default settings which is what you will get in the *absence* of an explicily defined set.

Modern DLT tapes have different requirements than DDS ones. The 'fbackup' and 'frecover' manpages for 11.23 and/or 11.31 do a good job of discussing some of the configuration file changes they you can make.

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, FSMs 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.

It is also noteworthy that in some release after 11.31, 'fbackup' will be deprecated and new 'fbackup' archives will not be able to be created.

Regards!

...JRF...
Fabian Brise├▒o
Esteemed Contributor

Re: frecover taking days to retrieve a file

hello randy.

What command are you using to retrieve the file ?

you can use a graph file to narrow down your recovery path
Knowledge is power.
Bill Hassell
Honored Contributor

Re: frecover taking days to retrieve a file

Something is broken...frecover can position anywhere on the DLT within a few minutes. I would look at patches for fbackup/frecover and also for the latest tape drivers. Always use a config file with fbackup -- the defaults are designed for reel-to-reel drives.


Bill Hassell, sysadmin