When encryption is done by the client, the key is stored somewhere on the
client machine (with Windows, it's encrypted and stored in the registry. 
For *IX, I think it's in /etc somewhere, also encrypted).

If you try to restore a file(s) to the same machine, the TSM client gets
the encryption key from its hiding place in the registry and decrypts the
file on the fly.

If you try to restore to any OTHER machine, the TSM client won't find that
key stored on the machine, and when you start the restore process you will
be prompted for the encryption key. If you have data that has been
encrypted with different keys, you're going to have a heck of a time
getting through the restore.  If you don't know the key, you won't get the
data back at all.

TDP's are different; you don't provide the key, it's created on the fly
and stored in the TSM DB, so you don't need to know what it is.

W


> I must admit I'm a bit confused on this option. Maybe someone who's used
> can give some advice. The questions I have revolve around testing in a
> DR environment where the server name on the other end would be different
> but the dsm.opt 'would' have the same name as the node at another site
> so as to be able restore that data. We currently export tapes for this
> process so I'm wondering how to get the data restored at the DR site
> once imported there if the data is encrypted. I've been reading the
> "readme" for one of the client 5.3 levels along with other things I can
> find, and although somewhat clear a bit confusing.
>
>
>
> Has anyone performed this type of data transfer at a DR site and if so
> what kind f issues did you run in to? Any specifics are welcome if you
> actually have the steps in place.
>
>
>
> Thanks,
>
>
>
> Geoff Gill
> TSM Administrator
> PeopleSoft Sr. Systems Administrator
> SAIC M/S-G1b
> (858)826-4062
> Email: geoffrey.l.gill AT saic DOT com
>
>
>