RESTORE from tape should prompt for alternate device

So I upgraded my SCSI internal DAT tape drive from an HP DAT72 to an HP DAT160. These drives are 100% compatible for DDS4 and DDS5 tapes, with either type of tape written by either drive subsequently readable by either drive. Yes, they have a different "device name" and "hardware id". But otherwise they are 100% compatible, subject to the caveat that DDS3 tapes are only usable on the DAT72 drives and DDS6 tapes are only usable on the DAT160 drive.

Nevertheless, all DDS4 and DDS5 tapes are usable interchangeably on either drive, for reading and writing no matter which drive is the writer and which drive is the reader.

Except... NovaBackup does not understand that.

In fact, the dozens of DDS4/DDS5 tapes I'd previously produced with NovaBackup using the DAT72 drive are NO LONGER USABLE DIRECTLY on the DAT160 drive. In other words I CANNOT USE THESE TAPE DIRECTLY INTO RESTORE... because "device not found".

Yes, since the device ID of the new DAT160 drive is different than that of the DAT72 drive which wrote the tape in the first place, NovaBackup rejects the RESTORE request with "device not found".



Now I have TWO suggestions for product improvement:

(1) In the event of such an error where tape is involved, instead of flat-out aborting the RESTORE the program should throw up a prompt for me to select an alternative input tape drive device (i.e. my new, current DAT160 tape drive) which should be used instead of the original tape drive as identified in the XML for the tape backup entry. This is essentially the same "Backup to..." dialog as I would go though when selecting the output tape drive device when building the backup job.

Obviously, the newly selected tape drive from this error-recovery dialog would then be used in place of the tape drive as identified in the XML description... and the RESTORE would then proceed normally.

This would permit me to just go ahead and continue to use the very original backup tapes produced with older, slower hardware, even after upgrading to newer, faster hardware... WITHOUT HAVING TO DELETE ALL THESE ENTRIES AND IMPORT EVERY ONE OF MY TAPES, WHICH COULD TAKE WEEKS!!!

In other words, the only current workaround that allows these tapes to be used is to IMPORT them using the new tape drive (and NovaBackup obviously allows that!!!). So why not just implement this same type of "acceptance" of the tape being read from the new drive at RESTORE time, just as is already allowed at IMPORT time!!!

It just takes a little side-trip out to the "select device" dialog during this early phase of RESTORE, to overcome the device id mismatch.

This is an unbelievably useful product improvement for anybody with tapes, lots of them, which took 3 hours to write and would take 3 hours to IMPORT if it had to be done... times dozens and dozens of tapes!!! IMPORT of all these tapes from the new tape drive COULD TAKE WEEKS!!!

(2) Now, if you look at the LOG screenshot above, you'll notice that THERE IS ZERO USEFUL INFORMATION OF ANY KIND!!!

Yes, the job failed. Yes, it was a "device not found" situation.

But, there is ZERO information in the LOG itself conveying what backup NBD dataset (session name, i.e. "media name") was the input to this failed RESTORE. Nor is there any information stating WHAT DEVICE WAS NOT FOUND!!!

Come on, surely the LOG should have useful information in it. That's why you created it. I don't need to see the date/time. I need to see useful information showing me what the clues are and why there was an error situation... spelled out.

These are nice ideas bud. Are these from experience?

These are nice ideas bud. Are these from experience?

These are from a GREAT DEAL OF EXPERIENCE WITH OTHER BACKUP SOFTWARE PRODUCTS, which handle tape a good deal slicker than NovaBackup does.

The backup dataset on tape should be "self-contained". It should have a "table of contents" header at the front which lists the contents of the tape. The contents should include a physical "tape index marker number" which should be used to precede each folder/file written to that tape. If you need to restore a folder/file from the tape, the table of contents should be read to find the "tape index marker number" and then a hardware SKIP FORWARD "so many index markers" command issued to the tape drive, to position the tape at that physical location.

In other words, the tape drive hardware supports this physical positioning capability at hardware fast-spin speed. A DAT cassette typically takes about 90 seconds to completely fast-forward from the beginning to the end, or to rewind from the end to the beginning... that's if you issue the SPIN command. And the drive can physically spin to a specific index marker point with a single command, using this high-speed motion. So, to locate the last file on the tape it shouldn't take more than 90 seconds to get there through the physical "spin forward" command to the hardware, at which time the RESTORE can immediately proceed.

Well, does NovaBackup work this way?? Definitely not.

(1) with NovaBackup there is no "table of contents" at the front of the tape volume.

(2) with NovaBackup there is no "index marker" concept written just in front of each folder/file on the tape, which would permit hardware fast-forward to that location with a single hardware command.

(3) in order to get to any file on the tape using NovaBackup, the tape must be READ CONTINUOUSLY, through every single data block on the tape, looking for the desired folder/file. This is done at READ SPEED (typically 2MB/sec for a DDS3-DDS5 tape and 6MB/sec for a DDS6 tape), which could mean up to 3 hours to position the tape through this ridiculous READ FORWARD method. In other words it takes as long to READ a tape as it does to WRITE the tape, meaning at data transfer speed. This is in contrast to hardware "spin speed" which is 90 seconds to get to the end of the tape by spinning it, instead of 3 hours to get there by READ'ing it.

(4) with NovaBackup there is no "volume serial number" label record written as the first record on the tape, put there by an INITIALIZE function (for pre-initializing new blank tape media into your "library"). This volume serial number label should never be written over (except by another INITIALIZE which should never be needed). Instead, each time the tape is mounted for use as output, the volume serial label record should be read to identify the possible current contents of the tape and compare it to the catalog of current non-expired tapes. If it is determined to contain another backup, the user should be prompted to accept this tape (for OVERWRITING with the new backup) or rejecting this tape (in which case it should be ejected). If it's a brand new tape (with no existing catalog entry) then a new catalog entry would be created to identify the now current contents of this tape. It it's an existing tape and OVERWRITE was confirmed, the old contents in the catalog should be erased and the new contents used to create a new catalog entry. The user doesn't have to specify a tape volume for use in a specific backup job (and then manually change the backup job definition the next time it's run to specify another tape volume). Instead, the user just mounts a new blank tape or an existing tape, and the program understands whatever it sees. In fact if it's a brand new uninitialized tape the user should be prompted to enter the "volume serial number" for insertion into that magnetic first volume label record on the tape, and the INITIALIZE function would be automatically performed.

(5) When a RESTORE from tape is requested, the catalog identifies the tape's volume serial number. The restore job itself identifies the hardware tape drive to be used. It is unnecessary that the tape drive hardware used to create the backup tape be the same tape drive hardware used to restore the backup tape. All that is obviously required is that the tape media is readable on the tape drive used at RESTORE time, and that the tape volume serial number label matches what the catalog entry says it should be... which of course assumes that the tape can be read from the current tape drive hardware. It is simply unacceptable that a tape written in the current catalog on this machine but using a different tape drive cannot just be instantly used for RESTORE on this same machine, as long as the current tape drive hardware can read that tape. It should not be necessary to do an IMPORT for all your tapes if you upgrade your tape drive to a newer larger faster device, but which is fully compatible with your old tapes.


Don't get me started about NovaBackup. They simply use tape as if it were disk, with virtually no conceptual differences that recognize the unique characteristics of a hardware tape drive.

Just a "bump" on this super-crazy product defect which make all of your previously created tape media backups unusable directly with RESTORE after a hardware upgrade or operating system and NovaBackup reinstall where the ID/BUS of the tape drive at RESTORE time is different from the ID/BUS in the BACKUP XML.

The requirement that you must now IMPORT each and every one of your existing tape media backups, something that could take weeks, before they are usable with RESTORE in the new environment is CRAZY!!!

Obviously, IMPORT can find the tape drive and use it with the new ID/BUS. The new hardware is "fully compatible". It's still the same SCSI tape drive, just with a different ID/BUS than what was present in the BACKUP XML. But it's actually 100% usable with the new ID/BUS values, as IMPORT will obviously prove.

RESTORE should be able to prompt for "select your restore device" with the exact same dialog as IMPORT, if there is this problem when RESTORE starts.

This is truly shamefully naive and defective product design and implementation with backup/restore software supporting tape drive devices (especially USB tape drives, whose ID/BUS may change).

I totally agree with the arguments of DSperber - it is a very, very bad design to handle a tape in such a sequential way.

Let's hope that NovaStor do a complete redesign on this subject.