My favorite scenario is the disgruntled employee: maintains critical 
corporate data on his system, backs it up using encryption, deletes the 
data from his system, then walks off holding the key hostage (paranoid, 
aren't I).  There isn't any way to know somebody is out there using 
encryption.  You can create a forced "exclude.encrypt *" entry in a client 
option set, but who thinks to do that?

The other issue is, what happens if the key is stolen?  There is no way to 
"change the password" for existing backed up files.  And if you change the 
key at the client, you wind up in a situation where a point in time 
restore will require different keys for files that were backed up at 
different dates.

_____________________________
William Mansfield
Senior Consultant
Solution Technology, Inc





"Joshua S. Bassi" <jbassi AT IHWY DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/03/2002 05:28 PM
Please respond to "ADSM: Dist Stor Manager"

 
        To:     ADSM-L AT VM.MARIST DOT EDU
        cc: 
        Subject:        RE: don´t aynone know anything about Encryption in TSM.


Andy,

What could a customer do for DR of a client which lost it's encryption
key and needed to restore data from the TSM backup (encrypted).


--
Joshua S. Bassi
Joshua S. Bassi
Sr. Solutions Architect @ rs-unix.com
IBM Certified - AIX/HACMP, SAN, Shark
Tivoli Certified Consultant- ADSM/TSM
Cell (415) 215-0326