Multiplex w/ KMS

[Jevon]

NetBackup 7.1.0.4 with the IBM TS3310 tape library.

It would seem I cannot perform Multiplex w/ Encryption (KMS).  The backup runs without error (false positive?). The tape is unreadable afterwards.

Anyone else share this experience?  How did you fix it?

[Rick_Stone · Accepted solution]

It is unlikely that the retention level or timestamps had anything to do with not being able to decrypt your data.  With KMS encryption, during a read process, the tape drive will encounter an encrypted block of data on the tape and notify the BPTM process via SCSI commands.  BPTM will then communicate with NBKMS on the master server to retrieve the encryption key.  Without actually seeing a restore failure from a full BPTM log we can't know if the tape drive is telling us if the data is encrypted or not.

One of the comments earlier mentioned that this is likely a firmware issue, and I would agree to that.
What model of tape drive are you using and what is the firmware version?  It wouldn't be the first time that we have encountered defective firmware that would cause this issue.  Check out the following technote:

www.symantec.com/docs/TECH204085

[Jevon]

1st Tape Library: ult3580-td4 Firmware: C7Q4

2nd Tape Library: ULT3580-HH5 - Firmware: B171

I don't recall seeing that doc before.  Yes, it could very much be the cause as the firmware is the same.  Funny, since I upgraded the firware quiet a bit since this problem was first detected.  Also, the only time it came up was when MPX was involved.  All non-multiplexed tapes decrypted fine.

If the problem comes up again, I'll post some BPTM details.

[mph999 · Accepted solution]

There is a bug that affects certain makes of drive due to a firmware issue. The drive is unable to correctly position after reading the backup header for the restore that is requested. Although this is not a NetBackup fault, there is a EEB that provides a workaround by getting the drive to read trough the headers as opposed to an ' mt -f ' which is what is failing. I'll try and find the details for his issue tomorrow (Fri) Martin

[jim_dalton]

Oddly I seem to be experiencing this issue...mpx encrypted backup, one key in the keygroup. Backup ( a good while ago) clean

16:39:47.340 [21900] <2> io_position_for_read: positioning 004291 to file number 25
16:39:47.340 [21900] <2> io_position_for_read: locating to absolute block number 291572
16:41:24.021 [21900] <2> io_position_for_read: locate block is done
16:41:24.132 [21900] <2> io_position_for_read: successfully positioned 004291 to file number 25, mpx_header = 3
16:41:24.134 [21900] <2> establish_decryption_key: next block encryption status: LON 0x00000000000472f7, algorithm index 1, encryption status 0x3
 

Restore job fails with permission denied on the device.

Had a firmware update on my LTO4s recently...would love to know the answer.

Im on 7504 Solaris Sparc.

Jim

[jim_dalton]

16:41:25.261 [21900] <16> mpx_read_data: cannot read image from media id 004291, drive index 3, Permission denied
 

Then error 40 from tar, then error 85 from media manager.

Love it.

Jim

[Rick_Stone]

16:41:24.134 [21900] <2> establish_decryption_key: next block encryption status: LON 0x00000000000472f7, algorithm index 1, encryption status 0x3
 

A return of 0x3 for encryption status indicates a response from the tape drive telling us that the data on the tape is not encrypted.  Because the drive is telling us the data is not encrypted, BPTM will not retrieve the encryption key details from NBKMS on the master server and will try to restore the data, which will result in status 85 in BPTM.

Since it is the drive telling NetBackup (via SCSI command) that the data is not encrypted, I would take a look at your firmware.  You say you just updated it recently.  What version are your tape drives currently running?

[mph999]

Opps apologies, forgot about this, I'll log in later and check the etracks. M

[mph999]

OK, found it.

eTrack  3093882 - and I have just realised this is the eTrack I posted previously.

This seems to be reported against 3592 drives, I am not sure what type you have.

It might be reasonable to try the etrack, but, depending on how the EEB works, it may be a code change that only affects 3592 drives, if you have another type, then it may need updating, but for this to happen Engineering will have to investigate that the issue is the same.

Perhaps you can post the case number up here, I'll contact the TSE involved and suggest they escalate to BL.

This issue / case has been going on too long.

Martin

[jim_dalton]

Good,interesting info Rick. I'm usng LTO4, and worried it thinks the data arent encrypted. Where does this info 0x03 originate? From the drive, by looking at the tape? If so then looking like a drive f/ware issues.

My drives are all at c7q0, im ultrium4.

Jim

[jim_dalton]

BBH4 works (IBM ultriums), just tested it.But it sems to me this is 2011 f/ware?

[Jevon]

The solution was to upgrade the firmware.  I finally got around to getting IBM to provide me with a newer firmware:  C7QH for the ULT3580-TD4 LTO4 tape drive.