Turning encryption OFF on LTO4 devclass

[james.dean]

All,

This is a very unusual requirement. I ned to see if anyone can help me with predicting what will happen.

We have a production LTO4 library with application encryption running. We've just found out our DR infrastructure can support LTO4, but won't do encryption.

Please, don't ask. But I can't replace it, I have to work in with it. I need to turn off encryption on the library, then put out a new set of unencrypted DR tapes.

Here's my question: If I alter the devclass from encryption=on to encryption=allow or encryption=off, I will start writing unencrypted tapes. Will I be able to read the encrypted tapes that are already in the onsite storage pools, or will this data become unavailable?

Please help. If it's the former, I will have a very simple change to make. If it's the latter, then I will need to create a migration plan to a new devclass with new storage pools.

Thanks,
James

 

[Eldoraan]

With Application Managed Encryption, with TSM controlling keys, you should be able to turn if off and eventually through reclamation all the current encrypted tapes will be scratched and rewritten unencrypted. When you get to Library Managed Encryption it can get real ugly if you can't access original key manager.

 

[cjhood]

Just be careful when using old encrypted tapes as scratch in your non-encrypted environment. I seem to recall that the volume label itself is encrypted and may not work properly in a drive or TSM environment that doesn't encrypt.

Relabeling the tapes (with overwrite=yes) will get around this.

Oh - and set driveencryption to 'no'. 'Allow' is for LME, better in my mind to just force it off completely.

-Chris

 

[Eldoraan]

Yeah, that's the ugliness with LME, if you lose the original key manager, it's a royal pain to get them relabeled (well, at least 3592 media). With AME, TSM should still have key when it's scratched, so it should be reusable without relabelling. It will just write next time non-encrypted. We have mix of AME and non encrypted tapes and don't have any issues when encrypted tapes scratch.

I had lots of issues with LME in a test library when we changed key managers. I had to define a non-encrypted logical library and relabel them non-encrypted before I could use them with 2nd key manager.

 

[james.dean]

Thamks

I still don't have a complete answer, but I've gotten around the issue anyway. I migrayed away from the encrypted storage pools into storage pool off an unencrypted devclass.

It's still a legitimate question - if you turn encryption off in a devclass for new stape from scratch, can the data on the encrypted tapes left in the storage pools still be read? The admin guide actually isn't clear - I know there would be no problem if you turned encryption on, what about the other way around?

James

 

[Eldoraan]

I answered that: Since TSM still retains the keys on the encrypted tapes internally until they scratch out, you can still read the old encrypted tapes after turning it off on devclass. You just won't create any new encrypted tapes. If you have any encrypted tapes with a Filling status, TSM will grab an unencrypted scratch tape rather than try to append since the devclass is set to No. You may need to do move data commands on the encrypted tapes to get data to uncrypted since reclamation levels may not hit some of the encrypted Filling tapes.

 

[james.dean]

Thanks; again.

Thanks. It wasn't entirely clear in your previous response, at least until I read it more closely.

What this seems to mean is that, disregarding LME, encryption=on and encryption=off mean start writing in that state, but does not preclude reading any tapes written in the prevoius state.

That seems the sensible way to do stuff, and it's good to see that TSM behaves that way. It wasn't guaranteed, though.

James