slow restore

[Victor_5]

K370, stand alone, 4 cpu, 4G memory, DLT7000. It is a test unit without any data. I rebooted the server and issued:
frecover -xovf /dev/rmt/1m -i /filesys_name

I used about 1 hour to restore 18G data, however, when the restore was finished and I issued the same command for another filesys at that afternoon, it costed me about 4 hours for 16G data, why so slow? What is the possible cause?

[James R. Ferguson]

Hi Shawn:

A couple of things are possible. I'm going to assume that the 'config' file used when the 'fbackup's were made was the same.

First, when 'fbackup' starts to copy a file it notes the timestamp of the file. When the file has been moved to tape, the disk timestamp is reexamined. If it has changed, the file (on tape) is marked "bad" and a recopy (from disk) is attempted. This can occur up to 'maxretries' times as defined in the 'config' file. The point is that you can consume substantial amounts of tape which will have to be read during a recovery before a good copy of the file can be restored.

Second, I'd suspect that in the slower case you had more small files than large ones. I believe that this makes for a slower recovery.

Regards!

...JRF...

[Bernie Vande Griend]

Couple of other thoughts: Are there 2 filesystems set up the same way? Same disk, same logical volume size? You said this was test, so other disk activity is probably not an issue here, but it can make a big difference with restore times other times.
My other thought is that if you have a lot of small files in that 16GB, trying doing the upgrade without the -v option. I've not tested on HP-UX, but on some systems the verbose can actually slow down the restore.