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.