Data verification time using frecover -V

[John Walker_1]

Following a fbackup task, I verify data/tape integrity by following it with a frecover -N command. The strange thing is, although the fbackup part may take 30 - 60 minutes, the frecover is taking in excess of 8 hours or more. Can anyone explain why this may be? I know read and write times can differ, but usually not noticeably so.

[John Carr_2]

Hi

can you post the command you use to backup the data in the first place please.

John.

[John Carr_2]

Hi

it could be that when you are doing your backup you are appending each time to the end of the tape, have you checked the output from frecover -N for multiple occurences of each file ?


cheers
John.

[Domenico_5]

hi john

if you try to create an index like:

# frecover -f /dev/rmt/0m -I index

The index created by the ???I option on frecover more accurately reflects the
true contents of the backup tape.

But another option that you can use to generate an index file for complete
listings of the files in the fbackup tape is :

# frecover -rovNf /dev/rmt/0m >/tmp/dryrun

work quikly or not?

bye

[Steve Steel]

Hi


frecover


-N (no recovery) Prevent frecover from actually recovering any files onto disk, but read the backup as if it was, in fact, recovering the data from the backup, producing the same output that it would on a normal recovery.

I presume your frecover runs while the machine is active.

You can only compare in the same circumstances


Also with a large file system you will swap a lot due to the space needed to keep the INDEX in memory.


The utility set comprised of fbackup and frecover was originally designed for use on systems equipped with not more than one gigabyte of total file system storage. Although the utilities have no programming limitations that restrict users to this size, complete backups and recoveries of substantially larger systems can cause a
large amount of system activity due to the amount of virtual memory (swap space) used to store the indices. Users who want to use these
utilities, but are noticing poor system-wide performance due to the size of the backup, are encouraged to back up their systems in multiple smaller sessions, rather than attempting to back up the entire system at one time. However, if the entire backup must be done with a single session, the user may encounter an error in frecover if there is not enough virtual memory available. If this happens, the user might consider adjusting the maxdsiz parameter or the swap space; both of these require a reboot.



Steve Steel

[John Walker_1]

John
The command initially used is:
/etc/fbackup -v -i $data_area -c $fb_conf -f $tape_dev

where the fb_conf parameters are:
blocksperrecord 256
records 32
checkpointfreq 1024
readerprocesses 6
maxretries 5
retrylimit 5000000
maxvoluses 200
filesperfsm 2000

Perhaps there is a parameter in here that is causing the issue?

[Steve Steel]

Hi

Many things affect backup and recovery, it would be interesting to do another backup and restore and monitor things like memory, disks and processors. Doing this could point you in a direction.


1)Change the /etc/sam/br/fbackup_config file
blocksperrecord 128
checkpointfreq 256
readerprocesses 4


Backup

2)Then try this
frecover -Nrosv -f /dev/rmt/0m > /tmp/logfile 2>&1


See how long it takes.


Steve Steel

[John Carr_2]

John

the backup method looks ok I would do as Dominon suggests and create an Index to file next. It will be interesting to see how long this takes.

good luck
john.