I should begin by making clear that I did not intend claim that the entire tape will always have to be read for each restore, but sometimes either all or a significant proportion might have to be read, and I apologise if I gave the wrong impression.

NetBackup organises data along a tape in sequential sections named “fragments”. Each fragment is a number of data blocks terminated by a tape file mark. The fragments of a single image (backup) can be distributed over many tapes and in a multiplexed backup each of these fragments can contain data from a number of different images.

I agree that NetBackup can reference the catalog to identify only the fragments that are required to restore a specific image and skip any fragments that do not contain data relevant to the restore, and that this can dramatically reduce the area of tape that needs to be read. Where, in my experience, this is not the case however is with multiplexed backups when the distribution of the data is such that every fragment contains data of the image that needs to be restored and must therefore be read. In such cases the multiplexed fragments contain data from multiple images, the gap between relevant data is significantly reduced and any fast block seeking capabilities of the tape drives are of little benefit as the drive is unable to seek quickly before the next relevant portion of data is required. Therefore the time to read and restore all images is multiplied by the number of multiplex images.

NetBackup doesn’t work that way. In general we would be skipping ahead as needed to just the data we need. There are exceptions of course, but you shouldn’t have to read 100% of the tape.

One exception might be if you have lost the NetBackup catalog and you need to recreate that from scratch. This underscores the neccessity of maintaining a good backup of the NetBackup catalog and practicing disaster recovery scenarios.

If you have questions feel free to email or comment.

thanks,

Tim Burlowski
Product Manager
Symantec