I got the same read error, but the scanner determine the label correctly. (It get the volume name)
I got unexpected file number errors too (expected 2 got 10)
Here is the scanner output:
8909:scanner: using '\\.\Tape0' as the device name 9000:scanner: \\.\Tape0: opened for reading 9003:scanner: \\.\Tape0: rewinding 8968:scanner: Reading the label... 8969:scanner: Reading the label done 39078:scanner: SYSTEM error: Tape label read for volume ? in pool ?, is not recognised by Networker: More data is available.
39078:scanner: SYSTEM error: Tape label read for volume ? in pool ?, is not recognised by Networker: More data is available.
8944:scanner: scanning for valid records... 8945:scanner: read: 131072 bytes 8945:scanner: read: 131072 bytes 8949:scanner: Found valid record: 8950:scanner: volume id 159018090 8951:scanner: file number 8 8952:scanner: record number 32 8955:scanner: volume name `LAP183L3' 8936:scanner: scanning LTO Ultrium-3 tape LAP183L3 on \\.\Tape0 8937:scanner: volume id 159018090 record size 131072 created 2/16/10 10:59:06 expires 2/16/12 10:59:06 9003:scanner: \\.\Tape0: rewinding 8973:scanner: setting position from fn 0, rn 0 to fn 2, rn 0 67559:scanner: scanning fn 10(2) rn 0(0) offset 0 len 276 8753:scanner: unexpected file number, wanted 2 got 10 8755:scanner: adjusting file number from 2 to 10 8758:scanner: scanning file 10, record 0 67559:scanner: scanning fn 10(10) rn 1(1) offset 0 len 276 67559:scanner: scanning fn 10(10) rn 2(2) offset 0 len 276
So the scanner output shows the data has been compromised (most likely by a SCSI reset to the drive as we are missing files 2-9 on the tape. Unfortunately this means the we will not be able to load the tape successfully in NetWorker as when we try and move to the end of the data we will hit different file marks than expected.
There are ways you can try and recover some of the data on the tape but most of the time its more trouble than its worth (if you can do this at all depending upon the type of data written Databases etc no good at all). I would suggest you look at the mminfo output for the volume and ensure you have good backups for the servers contained on this volume.
You can spot this as soon as it happens by enabling "verify label on unload" within the jukebox resource - this will check the NetWorker label when the volume is ejected from the drive, but this will slightly slow the servicing of requests as we perform this operation each time, but you find out straight away rather than when you try to recover the data. Some environments/Customers choose not to do this when they are really busy with lots of volume changes within the backup window.
As for the source of the SCSI reset it could be driver, incorrect zoning (server zoned to the drive which is not configured in NetWorker), TUR/RSM on Windows - there can be many causes but these are the most common.
As I said in my reply - it all depends upon the data that is backed up. If its just a flat file (or non module backup) then you may be able to recover the data left on the tape, but there must be no dependencies of other files/systems. It also depends what OS you have to read the tape and where the backup comes from. I believe it can be done for Unix but I am not aware of anything on Windows which can do this (I am willing to be corrected if someone knows how to do this.
So, with all the caveats above you can look at the scanner command and take advantage of the -x command with "uasm". Its probably not something with little NetWorker/UNIX knowledge will be able to succeed with. I would also not attempt this on the original server in case you overwrite something which is required.
Only method I know of when scsi reset have occurred and over written the header of the tape like this, (which is what appears to have happened), is to locate a data recovery service that can get the data from the tape. They have means to do this. Sometimes it can be costly.
One such company that I have found that can recovery from these scenarios and charge a reasonable rate is DataSpan. http://www.dataspan.com
Might want to talk with them or someone local to you who offers such services.
masonb
445 Posts
1
February 26th, 2010 08:00
Pal,
When you run scanner - does it report the NetWorker volume name? Does it report something like "expected file 2 got xxx"
Regards,
Bill Mason
paulo3
2 Intern
•
202 Posts
0
February 28th, 2010 12:00
Hi Bill!
I got the same read error, but the scanner determine the label correctly. (It get the volume name)
I got unexpected file number errors too (expected 2 got 10)
Here is the scanner output:
8909:scanner: using '\\.\Tape0' as the device name
9000:scanner: \\.\Tape0: opened for reading
9003:scanner: \\.\Tape0: rewinding
8968:scanner: Reading the label...
8969:scanner: Reading the label done
39078:scanner: SYSTEM error: Tape label read for volume ? in pool ?, is not recognised by Networker: More data is available.
39078:scanner: SYSTEM error: Tape label read for volume ? in pool ?, is not recognised by Networker: More data is available.
8944:scanner: scanning for valid records...
8945:scanner: read: 131072 bytes
8945:scanner: read: 131072 bytes
8949:scanner: Found valid record:
8950:scanner: volume id 159018090
8951:scanner: file number 8
8952:scanner: record number 32
8955:scanner: volume name `LAP183L3'
8936:scanner: scanning LTO Ultrium-3 tape LAP183L3 on \\.\Tape0
8937:scanner: volume id 159018090 record size 131072
created 2/16/10 10:59:06 expires 2/16/12 10:59:06
9003:scanner: \\.\Tape0: rewinding
8973:scanner: setting position from fn 0, rn 0 to fn 2, rn 0
67559:scanner: scanning fn 10(2) rn 0(0) offset 0 len 276
8753:scanner: unexpected file number, wanted 2 got 10
8755:scanner: adjusting file number from 2 to 10
8758:scanner: scanning file 10, record 0
67559:scanner: scanning fn 10(10) rn 1(1) offset 0 len 276
67559:scanner: scanning fn 10(10) rn 2(2) offset 0 len 276
Thanks for any help!
Regards:
Paul
masonb
445 Posts
1
March 1st, 2010 01:00
Pal,
So the scanner output shows the data has been compromised (most likely by a SCSI reset to the drive as we are missing files 2-9 on the tape. Unfortunately this means the we will not be able to load the tape successfully in NetWorker as when we try and move to the end of the data we will hit different file marks than expected.
There are ways you can try and recover some of the data on the tape but most of the time its more trouble than its worth (if you can do this at all depending upon the type of data written Databases etc no good at all). I would suggest you look at the mminfo output for the volume and ensure you have good backups for the servers contained on this volume.
You can spot this as soon as it happens by enabling "verify label on unload" within the jukebox resource - this will check the NetWorker label when the volume is ejected from the drive, but this will slightly slow the servicing of requests as we perform this operation each time, but you find out straight away rather than when you try to recover the data. Some environments/Customers choose not to do this when they are really busy with lots of volume changes within the backup window.
As for the source of the SCSI reset it could be driver, incorrect zoning (server zoned to the drive which is not configured in NetWorker), TUR/RSM on Windows - there can be many causes but these are the most common.
Hope that helps
Regards,
Bill Mason
paulo3
2 Intern
•
202 Posts
0
March 3rd, 2010 07:00
Hi Bill !
I there any workaround to get the data back from the cartridge?
Thanks in advance:
Paul
masonb
445 Posts
0
March 3rd, 2010 09:00
Paul,
As I said in my reply - it all depends upon the data that is backed up. If its just a flat file (or non module backup) then you may be able to recover the data left on the tape, but there must be no dependencies of other files/systems. It also depends what OS you have to read the tape and where the backup comes from. I believe it can be done for Unix but I am not aware of anything on Windows which can do this (I am willing to be corrected if someone knows how to do this.
So, with all the caveats above you can look at the scanner command and take advantage of the -x command with "uasm". Its probably not something with little NetWorker/UNIX knowledge will be able to succeed with. I would also not attempt this on the original server in case you overwrite something which is required.
Regards,
Bill Mason
HacknDos1
1 Rookie
•
66 Posts
0
March 10th, 2010 14:00
Only method I know of when scsi reset have occurred and over written the header of the tape like this, (which is what appears to have happened), is to locate a data recovery service that can get the data from the tape. They have means to do this. Sometimes it can be costly.
One such company that I have found that can recovery from these scenarios and charge a reasonable rate is DataSpan. http://www.dataspan.com
Might want to talk with them or someone local to you who offers such services.
Thanks
Paul