restoring from backup tape

[Eric Zumwalt_1]

I'm trying to restore a file that's on my backup tape. I did a listing on the tape and see the directory and file I'd like to recover but when I try recovering the file using SAM.
I get a message saying,

Volume 1 completed.
Press return when the next volume is ready /dev/rmt/0m.

The problem is, I don't have another volume. Is there a way to override that and get the info I need off the one tape.

Thanks,

Eric

[Bill Hassell]

SAM only understands the fbackup program and this program writes a complete directory at the beginning of every tape. Since there is no way to tell how many files will fit on the tape, a second or third tape may be needed and the directory at the front of the tape will be updated with the previous tape's list of files. Since it asked for the next volume, the file is not on this tape. You'll need to locate the 2nd tape.

[Bharat Katkar]

Eric,
Since it is asking for another tape that means the backup was taken on multiple tapes. Now either you have to locate that particular set of tapes or may be you are restoring from different tape rather than you actually intended to.

Hope that helps.
Regards,

[Eric Zumwalt_1]

So if I do a listing on that tape that doesnt mean that the files that come up on the listing will be on that tape?

[Dave Unverhau_1]

That's correct.

Here's what the man page has to say about it:

"Each file entry in the index contains the file size, the volume number and the pathname of the file. At the beginning of every volume, fbackup assumes that all files not already backed up will fit on that volume, an erroneous assumption for all but the last volume. Indices are accurate only for the previous volumes in the same set. Hence, the index on the last volume may indicate that a file resides on that volume, but it may not have actually been backed up (for example, if it was removed after the index was created, but before fbackup attempted to back it up). The only index guaranteed to be correct in all cases is the on-line index (-I option), which is produced after the last volume has been written."

Here's a link to the online manpages (volume 2), in case you want to read more on it:

http://docs.hp.com/hpux/onlinedocs/B2355-90681/B2355-90681.html

Best Regards,

Dave

[Bill Hassell · Accepted solution]

Correct. If you think about the backup process, it is serial, that is, you start recording and stop when the end of the tape is reached or when all the files have been stored on the tape. If the index were to be exactly correct, the program would have to go back and rewrite the index. That's very difficult to accomplish reliably. All the records in the index would have to be updated but there cannot be any tape errors requiring a retry. If an error occurs, the entire backup must be scrapped because a retry involves erasing the bad spot and writing the data further down the tape...which destroys the first file.

Unlike tar, cpio, dump, etc, fbackup maintains a central backup at the beginning of the tape which is only an estimate. If all the files fit on the tape, the index will be accurate. If some of the files do not fit, then a second tape is required. Note also that if a file disappears (removed) or the file is locked for read access, the index will indicate the file was scheduled for backup but a marker is recorded on the tape for the missing file. This technique is very common for commercial backup tools but they usually create a final index on disk as a database pointing to each tape.

The reason that tar, cpio, dump, etc seem to have an accurate listing is that they do not have ay index at all. Instead, these tools have to read the entire tape (a couple of hours) to create a listing.

My guess is that someone may have run this backup automatically and there was no one available to insert the second tape so the program was aborted. The backup was broken and no second tape exists. That's why it is critically important to review backup logs every day to make sure the backup was successful.