Try to position to that spot using mt and see if you get any error. If not, run scanner probe and see if you can read whole tape.

Some more details (working on running scanner)......

Cloning failing because of error "can not read record x". This has been occurring ever since the upgrade. This error will cause the clone job to fail on the entire volume, not just the SSID that has the error. There are some Knowledgebase entries that are similar and mention deleting the affected savesets and then scanning in the tape.

The problem is that it does not appear to be possible to identify the savesets that are failing without performing a clone of the savesets. Unfortunately, since the clone job fails as soon as it comes across this error, it would be difficult to identify the affected savesets. They would have to start a clone, wait for the error, make note of and delete the affected saveset, start the clone again, look for further errors and repeat until all savesets with this issue have been identified and deleted prior to scanning in the tape. We checked for flags using mminfo, but the affected savesets appear to be the same as the savesets that don't fail.

We would like to know if there's a way to identify all of the savesets on a volume that have this error without going through the cumbersome process listed previously. There are also many entries in the Knowledgebase mentioning block size mismatches as a possible cause. We verified that the block size is set the same on the backup server and at least 1 of the Windows storage nodes.

Thanks:) Scott

Is this scripted cloning or automatic one? In both cases if I remember correctly nsrclone would produce list of ssids on which failed. Depending on how scripted one is done you can avoid situation where cloning would fail to process other ssids after it encounters faulty one (or the one where error is). Unfortunately both cloning and staging suffer from this and as I said there are ways how to bypass it via scripted method, but such approach would downgrade overall time required for cloning.

The quickest way to test this is to load the tape to drive (where error occurred), go to CLI and issue mt -f rewind, them mt -f fsf 169 which should position you on file number 169 of that tape (007050A0). AFAIK you don't need mt -f fsr 0 after as you should be there already. If there is a problem with positioning to that block on tape you should get an error already here.

scanner is another approach, but it takes some time. Of course to speed it up you could simply just scan saveset in question (eg. 4073807781). mminfo should also provide information about file and record mark on which ssid starts.

To identify which ssids fail you can use also mminfo and inspect number of copies.

I think failed ssid should also get suspect flag in clflags column.

block size could be the issue, but I doubt something in that direction would change after application upgrade.

Ok, the clflags helped identify the "suspect" savesets. The clones are scripted and kicked off through cron, and clone to tape from CDL and EDL to LTO-2. After the 7.3.3 upgrade, the scripts started to hang whenever it hit a suspect ssid, and didn't continue cloning (filling up the VTL's).

Our best guess is that restarting networker while some RMAN's were running caused the suspect ssid's. This had hapened before the upgrade but the cloning didn't hang.

Anyhow, we scripted running mminfo on all volumes with the clflags and it identified all suspect ssid's, which was our primary goal. We'll keep the script in place for now and see if we continue to get suspect ssid's (all but one were of RMAN backups).

Of note is that I couldn't restore with the recover command using the suspect ssid, and we later found out we were able to change the ssid from suspect to normal (but didn't try restoring after that)

Many thanks, and if you're ever in Philadelphia, lunch is on me:)!