CTE-LDT Policy for Encrypted Backup and Restore

Suppose you have an CTE-LDT policy allowing a backup user, or a backup process, to perform an encrypted backup. The backup user, or the backup process, reads encrypted data from files and stores the same encrypted data in backup media.

For example, suppose you wanted to back up GuardPoint /oxf-fs1/gp1 protected by My_LDT_Policy_1. The key version before the key rotation is 8. The following steps occur:

1. Key version 8 expires and is rotated to version 9.

2. Rotating the encryption key triggers CTE-LDT to start running on the data under the GuardPoint.

3. The QoS schedule suspends CTE-LDT because a backup process is running.

4. The backup process begins, runs and later ends.

5. The QoS schedule resumes CTE-LDT.

6. CTE-LDT on the GuardPoint completes.

Note

Although the backup/restore scenarios and examples described in the rest of this section are specific to CTE-LDT on Linux platform, the concepts also apply to CTE-LDT on the Windows platform.

Consider the state of the three files in the GuardPoint during the CTE-LDT process, right after CTE-LDT is suspended in preparation for the backup. You can obtain the state of each file through the voradmin ldt attr get command, which examines the CTE-LDT state of each file captured in the CTE-LDT extended attributes of those files. (For an overview of voradmin CTE-LDT, see CTE-LDT Command-Line Administration: voradmin command).

• File_1.dat is rekeyed/encrypted to completion. The applied and new key versions are at version 9 of the key.

  voradmin ldt attr get /oxf-fs1/gp1/data_files /file_1.dat
  LDT attributes: rekeyed_size=1440743424, rekey_status=none
   Key:    name=LDT_AES256_KEY, version=9

  Copy

• File_2.dat is partially rekeyed/encrypted. The applied key version is at version 8 and the transformation key is at version 9.

  voradmin ldt attr get /oxf-fs1/gp1/data_files/file_2.dat
  LDT attributes: rekeyed_size=1440743424, rekey_status=rekeying,state_saved
  Current Key:    name=LDT_AES256_KEY, version=8
  New Key:        name=LDT_AES256_KEY, version=9

  Copy

• File_3.dat has not been rekeyed/encrypted. The applied key and transformation key are both at version 8, which is the version before the current key rotation.

  voradmin ldt attr get /oxf-fs1/gp1/data_files/file_3.dat
  LDT attributes: rekeyed_size=1440743424, rekey_status=none
  Key:    name=LDT_AES256_KEY, version=8

  Copy

While CTE-LDT is suspended on the GuardPoint, the backup process starts and archives these three files, including extended attributes, in the backup media.

my_backup --preserve=xattr /oxf-fs1/gp1/data_files/file_1.dat \
    /backup-media/oxf-fs1/gp1/data_files/file_1.dat
my_backup --preserve=xattr /oxf-fs1/gp1/data_files/file_2.dat \
             /backup-media/oxf-fs1/gp1/data_files/file_2.dat
my_backup --preserve=xattr /oxf-fs1/gp1/data_files/file_3.dat \
             /backup-media/oxf-fs1/gp1/data_files/file_3.dat

Note

• On Linux platforms, you must perform backups on a GuardPoint during periods when CTE-LDT is not actively transforming data in the GuardPoint. You must schedule backups in conjunction with CTE-LDT schedules or during periods when CTE-LDT is paused. Make sure to coordinate with the backup administrator and schedule accordingly.

• If the preferred method of backup is to create device level snapshots of the file system on the managed host or in the storage array subsystem, you must ensure that the schedule for creating snapshots pauses CTE-LDT before a snapshot is created.