The truth about uvrestore

After finding there were differences in the behaviour of uvrestore  between AIX and RedHat Enterprise Linux platforms (see Facts about uvbackup and uvrestore) I performed some tracing on the uvrestore command (using the strace command in Linux).

Undocumented behaviour

The first read  of the backup image attempted by uvrestore is a 512-byte block size. It makes no attempt to detect the current block size of the backup image. This 512-byte read is obtaining the tape header written by uvbackup, and the header contains the block size used by uvbackup to create the backup image. Once the block size of the backup image is determined, all future reads of the backup image use the detected block size.

This initial read of a 512-byte block is what is causing all the issues, as it is up to the operating system to deal with an attempt to read a block size that might not match the backup image device block size (tape drive block size).

AIX

On AIX, if the backup image was created on a tape device with a block size larger than 512 then uvrestore needs the tape device block size to be set to automatic (i.e. zero) to be able to succesfully read it. AIX’s support for reading from a device with an automatic block size setting makes this the most flexible approach.

Recommendation

Set AIX tape device block size to automatic before running uvbackup and uvrestore. This will allow you to maximise the block size used, helping to maximise the performance of uvbackup and uvrestore.

Linux (RHEL)

On RHEL, the support for reading from a tape device with an automatic block size seems to be flawed.

If the block size of the tape device was automatic (i.e. zero) when uvbackup was run to create the backup image, then uvrestore will only be able to read the backup image if one of the following conditions exist:

• The block size of the tape device is still automatic and the block size used by uvbackup is 512
• The tape device block size is adjusted to match the block size used by uvbackup

If the block size of the tape device was larger than 512 when uvbackup was run then it must be set to the same value when uvrestore is run.

Beware of tape device driver versions

The behaviour of the tape device driver is a critical factor in the behaviour of uvrestore on RHEL (my tests where done using an LTO-3 or LTO-4 tape drive, which uses the st device driver).

I found that RHEL4 has a st tape device driver problem that can cause a running system to panic and seize up if the tape device block size is set to a value larger than 512 and uvrestore is used to access a backup image. The st driver has a bug when driect I/o is enabled and a read of less than a full block is performed. The fix was to turn off direct I/O for reading.

The point is, RHEL does not have the same support for a tape device block size of automatic when reading, as AIX does. Some device drivers do have flaws, so test the block size permutations on your hardware.

Recommendation

1. Set the tape device block size to match the uvbackup block size before running uvrestore
2. Test tape device hardware using both uvbackup and uvrestore with a block size larger than 512 to ensure there are no issues with the hardware or device drivers

Incorrect documentation

All versions of the uvrestore documentation I have seen indicate that the command can be provided a block size parameter using the syntax:

-b <block_size>

Having seen the 512-byte read, followed by the use of the block size in the backup image header, I suspected that this command-line parameter was being ignored. I confirmed this with Rocket Software U2 support.

The uvrestore command completely ignores the -b <block_size> parameter, so there is no need to supply it to the command.