DRM Tape Encryption Keys

[wildbill9999]

We do our Disaster Recovery at a remote site and we restore a mix of about 30 servers, Win 2003, HP-UX, AIX, Linux. These servers are not identical to the original servers so the restores use the -virtualnodename parameter to identify the original server. I have a set of scripts that run the restore jobs within their collocation groups using a tape library with six drives. This avoids having to manually start and monitor every restore. All this has been tested many times and works well.

Now, I am required to encrypt the DRM tapes. All my dsm.opt files specify "encryptkey save". This works fine until I run a DR test. I find that each directory I restore on each server will prompt me for the encryption key before it restores any encrypted files. Even though I use the same key for every backup on every server, I specify "encryptkey save", and I establish that key on each DR server, I am still prompted to enter the password manually for every directory I restore. This is extremely labor-intensive for a large DR that runs for two days. And tiring!

I might overcome this with a "Here document" on the Unix servers (haven't tested that yet, but it should work), but there's no such thing for Windows.

Does anyone know a way to overcome this limitation? Some way to persuade the DR server to accept the stored encryption key, or stop prompting after the first entry, or any other method that might help?

Does anyone know a way to persuade the DR servers to

[heada]

Have you tried to change the nodename in the dsm.opt/dsm.sys file rather than use the virtualnodename option? The TSM nodename doesn't have to match the OS hostname and it might work better with the encryption if the host encryption key matched the TSM nodename.

-Aaron

[wildbill9999]

Good idea, HEADA. However, we are doing application stacking at DR, which means we are restoring the applications from several servers onto one server at DR (we have several servers at the DR site, but not as many as we have in the originating data center). I think that would require we modify the dsm.opt file for every restore in order to have the appropriate name in place. It's probably worse than entering the encryption key.

[heada]

Have multiple dsm.opt files and have your restore point to the one you are restoring from.

-Aaron

[wildbill9999]

Thanks. I'm gonna try that. Sounds like it might work. I'll post results.