11-12-2012 08:01 AM
Can anyone tell be whether it is OK to mix encrypted savesets and unencrypted savesets on the same tape?
For example, if I have 3 savesets on a tape. SS1 is written using encryption key K1, SS2 is written with K2, and SS3 is not encrypted.
Question 1 is: Is this OK? (without discussion about whether it is advisable or anything else)
If I subsequently want to restore SS3, will this be a problem?? (just trying to get a better understanding of the encryption process when using Backup)
11-12-2012 10:29 AM
Save sets are independent files on a tape, regardless whether they are encripted or not. HP documentation says that key information is stored inside a save set and therefore does not affect the other save sets:
Any save set is an ordinary file from the viewpoint of the VMS file system. In particular, it can be copied from a tape to a disk and then used directly from the disk in which case the qualifier /save_set must be added to the file name. The command "$ dir mkxxxx:" will show what files are there on the magtape (mounted in native mode, not foreign). Save sets and ordinary data files can be mixed on the same magtape. The only difference is that ordinary data files have 4 head/tail blocks HDR1, HDR2, HDR3, HDR4 while save sets have only 2 of them. This can be seen by the command "$ dump mkxxxx:".
11-13-2012 09:51 AM
As Alphacat points out, there is no documented issue in mixing encrypted and unencrypted save_sets. I can add I've done this in a production environment, with test restores on bare Alphaservers without issue.
In our case, save_set_1 is unencrypted (recovery o/s with Encrypt installed) and follow on save_sets are encrypted. This option allows restoring from stock bootable media without reinstalling Encrypt, but also requires no protected data be allowed on the system disk tape. Maintaining copies of the encryption keys and ensuring those aren't transported with your backups is another potential risk issue.
11-13-2012 10:10 AM
Hm, I have this vague recollection about a BACKUP bug that when using some BACKUP operations using wildcard for save set names failed to switch the encryption context between encrypted save sets on tape.
Should all be fixed in recent versions.