Media Read Error(85) tapemark or blank tape encountered reading media header Very Urgent Customer is esculating in higher Range

[Mistaken333]

Dear All,

  We are facing the below  issue while restoring data from tapes Media Read error(85), eventthough the media has data which has a retention period of 6 months Please help us three days we are struggling we are not able to restore a single data from tapes. Please find teh below logs

7/23/2015 8:50:11 PM - begin Restore
7/23/2015 8:50:14 PM - 1 images required
7/23/2015 8:50:14 PM - media O988L5 required
7/23/2015 8:50:16 PM - restoring image XYZABC_1427576616
7/23/2015 8:50:18 PM - Info bpbrm(pid=12208) XYZBCK is the host to restore to      
7/23/2015 8:50:18 PM - Info bpbrm(pid=12208) telling media manager to start restore on client     
7/23/2015 8:50:18 PM - Info bpbrm(pid=12956) XYZBCK is the host to restore to      
7/23/2015 8:50:19 PM - connecting
7/23/2015 8:50:20 PM - Info bpbrm(pid=12956) start tar32 on client         
7/23/2015 8:50:21 PM - Info bptm(pid=14180) Waiting for mount of media id O988L5 (copy 1) on server XYZbck.abc.com.
7/23/2015 8:50:21 PM - started process bptm (14180)
7/23/2015 8:50:21 PM - mounting O988L5
7/23/2015 8:50:21 PM - requesting resource O988L5
7/23/2015 8:50:21 PM - granted resource O988L5
7/23/2015 8:50:21 PM - granted resource HP.ULTRIUM5-SCSI.002
7/23/2015 8:50:22 PM - Info bptm(pid=14180) INF - Waiting for mount of media id O988L5 on server XYZbck.abc.com for reading.
7/23/2015 8:50:23 PM - Info tar32(pid=13576) Restore started.           
7/23/2015 8:50:23 PM - connected; connect time: 00:00:04
7/23/2015 8:51:31 PM - Error bptm(pid=14180) tapemark or blank tape encountered reading media header, drive index 3  
7/23/2015 8:51:31 PM - Info tar32(pid=13576) done. status: 0          
7/23/2015 8:51:31 PM - Info bpbrm(pid=12208) child done, status 0         
7/23/2015 8:51:34 PM - Info bpbrm(pid=12208) got ERROR 85 from media manager       
7/23/2015 8:51:34 PM - restored image XYZABC_1427576616 - (media read error(85)); restore time 00:01:18
7/23/2015 8:51:35 PM - Warning bprd(pid=11712) Restore must be resumed prior to first image expiration on 10/1/2015 2:33:36 AM
7/23/2015 8:51:35 PM - end Restore; elapsed time: 00:01:24
Restore error(2850)

We are using windows server 2008 Enterprise and Tape Library HP MSL 8096, Please help us urgent

[Mistaken333]

Dear All,

    Can you please guide me on this.

[Marianne]

"Error bptm(pid=14180) tapemark or blank tape encountered reading media header" Not much anyone can do about this. The tape header cannot be read by the tape driver. Was media written in another environment where encryption is used? Or anything else happened to tape that could wipe the header? You can try to verify the tape or run media contents report, but it seems that it will produce the same error.

[mph999]

The chances of reading this tape are probably very low, no header means NBU can't read it, and usually there is no way around this.

As Marianne asked, is encryption used, and if so, how :

Tape library encryption

MSEO

KMS ???

We can read the tape as show below, post up the output, you will need to put in the correct media ID and tape drive path, what is shown below is just an example.

This probably won;t give us a cause, but it might give a clue as to what is on the beginning f the tape.

Load the  'problem' tape into a drive with the following command, it will take a few moments for the command prompt to return In this example I have used media id E03002, please use the media ID for your tape.

tpreq -m E03002 -f E03002

Run vmoprcmd command (in volmgr\bin dir), this will show which drive the tape is in.

IBM.ULT3580-TD4.001 Yes Yes E03002 E03002 Yes hcart
nbmaster1 /dev/nst4 SCAN-TLD
nbmedia1 {4,0,1,3} ACTIVE

Here we see the tape is loaded in the drive with the path {4,0,1,3}

Next, run scsi_command -map -d {4,0,1,3} command (substitute the correct drive path in from vmoprcmd output) and output this to a file

scsi_command -map {drive_path} >scsi_map_output.txt

[Mistaken333]

Dear All,

          Hardware encryption is not enabled in Library for Sure we checked with Library Vendor, We are moving the media to offsite IS  this cause problem, recently, last month we have restored some data from the  same media at that time we have used the command bpimage -newserver hostname -id O988L5 is this cause any problem to the media, we cannot able to restore any data not only from this tape from all Monthly media (ieApril March June). Please help and sugget very critical please

[mph999]

I have suggested the next steps, please read my post and follow my example.

Moving tapes and vmchange commands will not cause this issue.

This tape is not going to be recoverable, without a tape header there is no way to get netbackup to read the tape.  The header cannot be replced, without 'expiring' the tape, which would write a new EOD filemark, meaning the tape couldn't be read past this point.

All my instructions will do, is maybe give some clue as to what has happened to the tape, there is no way to 'repair' it.

So.

1.  Please answer my questions below

Do you use MSEO encryption ?  (Media server encryption)

As a matter of interst, in your environment, are the tape drives shared with any NDMP devices, for example, NetApp Filer.

2.  Follow my example above to read the tape with scsi_comand

NOTE:

As mentioned, it is almost 100% certain that this tape is not going to be recoverable.  All we can really do is try and see if we can get some clues as to what has happened.

[mph999]

Any update on this ?

[Genericus]

I would check the tape to see if you can read it at the source site.

If you can read it where you wrote it, that might point to an issue.

You need to isolate the differences and eliminate them one at a time.

It certainly sounds like there is an encryption key in play.

[mph999 · Accepted solution]

Given this affects more than one media it's probably not bad media (not impossible, but not that likely), I would suggest you log a call with Symantec and post the case number up here, I will take a look at it.

It is not mentioned that encryption is used, it's possible that if it is, it could cause symptoms like this - however of the encryption issues I have been involved in, you can usually mount the tape (ie. the tape header is readable).  MESO can encrypt the headers, it's not really advised, and isn't default behavior.  KMS encrypts everything, so again maybe possible.

However, we asked about library encryption and it was stated that it wasn't used.  Hopefully, if some other encryption was used, it would have been mentioned at that point.  "No, library encryption is off, but we are used xxx encryption ..."

Another possibility is something is causing the drive to rewind mid-backup, this is impossible to detect at the time it happens, the OS can't detect it, and it is the OS that is writing the data to the drives, not NBU - the usual cause of this is multiple 'machines' that see the drive are using different types of SCSI reservation - typically this is a media server and NDMP device, eg NetApp.  The result is that the beginning of the tape is overwritten by 'data' making it impossible to recover.  It should, I have thought, be detectable at the end of the backup as the block position check will fail (the tape isn't positioned where we have calculated it should be).  However, if block position check is off there would be no way of telling, till you try and restore (which is why block positioon check should never be disabled, apart from one off tests).

scsi_command -map would show this, as the size of the block at the beginining of the tape will not be the 1K header, but whatever SIZE_DATA_BUFFERS is set to, eg 128K.

There are other possibilities, but on windows at least, scsi_command -map is a very good starting point, mainly as there are limited tools available for reading the tape outside NBU, scsi_command is one, nt_ttu is another, and that's about it, unlike Unix/ Linux where you have dd, tar, cpio, scsi_command, tcopy (on solaris) - which makes investigation of these types of issues so much easier (well, hopefully easier).

It needs looiking at fairly urgently, as there is always the possibility that every tape written is going to have this issue.  We might not be able to recover the old tapes, but we can stop more tapes suffering the same fate.