• Please help support our sponsors by considering their products and services.
    Our sponsors enable us to serve you with this high-speed Internet connection and fast webservers you are currently using at ADSM.ORG.
    They support this free flow of information and knowledge exchange service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions
  • Community Tip: Please Give Thanks to Those Sharing Their Knowledge.

    If you receive helpful answer on this forum, please show thanks to the poster by clicking "LIKE" link for the answer that you found helpful.

  • Community Tip: Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING)

    Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.

Enabling tape encryption

JensD

ADSM.ORG Member
#1
Hi

I've been looking at setting up data-at-rest encryption all over, and I've come to our backups in TSM (v7.1.6.0) on Linux, and I need some advice or pointers to the right parts of the documentation that have been unable to locate myself.

For everything on disk (random STGPs for incoming data, on-disk STGPs for main storage and later copy to on-tape copy STGPs), I'm going to migrate the individual LVM PVs for all LVs to new LUKS/dm-crypt'ed PVs, so everything should be transparent to TSM.


For all data tape volumes, what are the caveats for just updating my LTO4 library deviceclass to DRIVEEncryption=ON and have TSM manage the keys - will TSM just begin to write encrypted data the next time any STGP data is written?

I cannot find any mention of how I ensure that all existing tapes are repopulated with encrypted data, but I would need that to happen as well - hopefully without having to resort to setting ACCESS=DESTROYDD for all tape volumes to force TSM to rewrite data from the on-disk STGPs, but what are my options here?

Furthermore, I can see that I need to secure a copy of the master encryption key somehow.
In TSM v7.1.8 there was an optimization/improvement mention here: https://www.ibm.com/support/knowledgecenter/en/SSGSG7_7.1.8/srv.common/r_techchg_srv_ekey_718.html, but as I'm currently running v7.1.6, does that mean that I have to back up dsmserv.pwd myself, or can I just run DB backups with options PROTECTKeys=YES and PASSword=<some password> and then just keep the chosen password safe?

I also take it, that when I eventually come around to upgrading to later versions of TSM I either have to secure copies of cert.kdb, dsmkeydb.kdb, cert.sth and dsmkeydb.sth (mentioned in the like above) or just use PROTECTKeys=YES and PASSword=<some password> as with v7.1.6?
 

ianr27

ADSM.ORG Member
#3
Hi

I've been looking at setting up data-at-rest encryption all over, and I've come to our backups in TSM (v7.1.6.0) on Linux, and I need some advice or pointers to the right parts of the documentation that have been unable to locate myself.

For everything on disk (random STGPs for incoming data, on-disk STGPs for main storage and later copy to on-tape copy STGPs), I'm going to migrate the individual LVM PVs for all LVs to new LUKS/dm-crypt'ed PVs, so everything should be transparent to TSM.


For all data tape volumes, what are the caveats for just updating my LTO4 library deviceclass to DRIVEEncryption=ON and have TSM manage the keys - will TSM just begin to write encrypted data the next time any STGP data is written?

I cannot find any mention of how I ensure that all existing tapes are repopulated with encrypted data, but I would need that to happen as well - hopefully without having to resort to setting ACCESS=DESTROYDD for all tape volumes to force TSM to rewrite data from the on-disk STGPs, but what are my options here?

Furthermore, I can see that I need to secure a copy of the master encryption key somehow.
In TSM v7.1.8 there was an optimization/improvement mention here: https://www.ibm.com/support/knowledgecenter/en/SSGSG7_7.1.8/srv.common/r_techchg_srv_ekey_718.html, but as I'm currently running v7.1.6, does that mean that I have to back up dsmserv.pwd myself, or can I just run DB backups with options PROTECTKeys=YES and PASSword=<some password> and then just keep the chosen password safe?

I also take it, that when I eventually come around to upgrading to later versions of TSM I either have to secure copies of cert.kdb, dsmkeydb.kdb, cert.sth and dsmkeydb.sth (mentioned in the like above) or just use PROTECTKeys=YES and PASSword=<some password> as with v7.1.6?
Hopefully you managed to find a way around this but if not, you'll need to do the drive encryption in the device class like you say. Once that is done you should notice when you do a 'q vol <vol name> f=d' that the volume now has a key manager.
To encrypt the older volumes, you'll need to run a move data against each of the unencrypted volumes.

The keys article which you're looking at is if you're utilising client encryption. Turning it on for the drive will mean that the keys will be managed by TSM and will be stored in the internal database. Meaning that the TSM database backup, if done to tape, will not be encrypted, so I would recommend that you back up the database to disk or NAS elsewhere in your environment through a file device class
 

JensD

ADSM.ORG Member
#4
Hopefully you managed to find a way around this but if not, you'll need to do the drive encryption in the device class like you say. Once that is done you should notice when you do a 'q vol <vol name> f=d' that the volume now has a key manager.
To encrypt the older volumes, you'll need to run a move data against each of the unencrypted volumes.

The keys article which you're looking at is if you're utilising client encryption. Turning it on for the drive will mean that the keys will be managed by TSM and will be stored in the internal database. Meaning that the TSM database backup, if done to tape, will not be encrypted, so I would recommend that you back up the database to disk or NAS elsewhere in your environment through a file device class
Hi, thanks for replying

No, I have not started encrypting the tapes - yet - but it's nice to know that it should "just work" by setting DRIVEEncryption=ON and issuing a few(!) "move data" commands.


Where do you see that the article I linked to related to client encryption?
As far as I can see the link describes a new feature in TSM server v7.1.8 that mentions that the master password will me migrated from dsmserv.pwd to cert.kdb, dsmkeydb.kdb, cert.sth and dsmkeydb.sth and that a master encryption key is automatically generated if it didn't exist before the upgrade.

I'm doing backups of TSMs DB onto tape (using the same deviceclass as the STGP volumes that will be encrypted) as well as onto disk using a FILE deviceclass, but I need to be absolutely sure that the copy written to either FILE or tape can still be accessed if I have dsmserv.pwd (when running TSM < v7.1.8) or cert.kdb, dsmkeydb.kdb, cert.sth and dsmkeydb.sth (when running TSM >= v7.1.8) and the password used to protect the DB backup - kind of what is required in a DR situation, where I have to bootstrap TSM.
 

Advertise at ADSM.ORG

If you are reading this, so are your potential customer. Advertise at ADSM.ORG right now.

UpCloud high performance VPS at $5/month

Get started with $25 in credits on Cloud Servers. You must use link below to receive the credit. Use the promo to get upto 5 month of FREE Linux VPS.

The Spectrum Protect TLA (Three-Letter Acronym): ISP or something else?

  • Every product needs a TLA, Let's call it ISP (IBM Spectrum Protect).

    Votes: 17 19.5%
  • Keep using TSM for Spectrum Protect.

    Votes: 53 60.9%
  • Let's be formal and just say Spectrum Protect

    Votes: 10 11.5%
  • Other (please comement)

    Votes: 7 8.0%

Forum statistics

Threads
31,468
Messages
134,123
Members
21,569
Latest member
srinathkodela
Top