Backup/Restore of Metadata Store File (MDS) in GuardPoints Undergoing Rekey

• Restoring a GuardPoint from a Backup

• Potential Warnings During Restore Operation

Backing up an entire GuardPoint using commands such as cp, tar, or rsync, or even commercial backup products that sweep the file system namespace for backing up files is supported. This method of backup performed while live transformation is in progress over GuardPoint poses some challenges when files in GuardPoint are backed up in encrypted format. The challenge with this method of backup is existence of the CTE-LDT Metadata Store file (MDS) in GuardPoint during backup or restore process and strict protection enforced on MDS files preventing deletion or modification to MDS files. Second, your backup utility must backup and restore extended attributes of files and the GuardPoint directory, and because CTE-LDT extended attributes are also protected similar to MDS files, your backup must be enabled to restore extended attribute of files. To overcome both restrictions, your policy on GuardPoint must include a security rule without Apply Key Effect to enable your backup utility to replace MDS file and CTE-LDT extended attribute of files as part of backup/restore operations. Additionally, your backup utility must be signed with a signature set from the CipherTrust Manager for added security, and be executed with the option to preserve extended attribute options available with the standard Linux utilities.

The following table lists the supported backup utilities, required options to preserve extended attributes, and supported versions of the utilities.

You can also backup and restore GuardPoint data, including the MDS file, if the requirements listed above on the backup utility are satisfied. GuardPoints associated with an MDS file located outside of GuardPoint namespace cannot be backed up or restore using this method of backup.

You must suspend CTE-LDT on GuardPoint before performing backup or restore.

You can check your GuardPoint to determine if you can use this method of backup. If the directory of your GuardPoint is a mount point, MDS files reside inside your GuardPoint and this method of backup can be used for backing up or restoring your GuardPoint. However, GuardPoint directories below file system mount points must be checked and verified to use this method of backup. To verify, you can run the voradmin command to determine the MDS file associated your GuardPoint.

For example:

voradmin ldt list all
MDS_1:  type=file, nguards=1, name=/oxf-fs1/gp1/::vorm:mds::

Guard Table: version 1 nentries 1
Guard 0: type=GP, state=REKEYING SUSPENDED (vadm), flags=GP LOCKED, gp=/oxf-fs1/gp1
File List: count 4308

The report on /oxf-fs1/gp1 GuardPoint indicates association of the MDS file /oxf-fs1/gp1/::vorm:mds:: with the GuardPoint. As the MDS file resides inside the GuardPoint directory, you can use this method of backup to backup and restore this GuardPoint.

Before restoring the GuardPoint, you must suspend CTE-LDT operations on the GuardPoint if live transformation is in progress. Failure to do so will fail to restore the MDS file in the backup image. Failure to restore MDS file affects partially rekeyed files restored to the GuardPoint. In such a situation the restored data is invalid, and you must remove all the files restored to the GuardPoint and repeat the restore operation after suspending CTE-LDT.

Restoring a GuardPoint from a Backup

To properly restore GuardPoint along with the MDS file, the following steps must be done in order:

1. Verify if live transformation is in progress on the GuardPoint and suspend the CTE-LDT operations. (Skip this step if no live transformation is occurring.)

2. With the same tool that was used for backup, restore to the GuardPoint.

3. Once restore is complete, GuardPoint needs to be disabled and enabled again. Run the voradmin command as shown below to determine how the GuardPoint was suspended at the time of backup. For manual GuardPoint, run the secfsd command as shown below. For auto-guards, disable and enable GuardPoints on CipherTrust Manager.

   secfsd -unguard <GuardPoint>
   secfsd -guard <GuardPoint>
   

4. Since GuardPoint was in suspended state during the time of backup, it will be restored in suspended state. You must resume CTE-LDT to complete CTE-LDT on the restored GuardPoint. You must resume CTE-LDT on the CipherTrust Manager if CTE-LDT was suspended on the CipherTrust Manager at the time of backup, otherwise you will resume CTE-LDT using voradmin command.

   Run the voradmin command below to determine if CTE-LDT must be resumed on CipherTrust Manager or through voradmin. If the tag string next to SUSPENDED state of GuardPoint is vadm, run voradmin command to resume CTE-LDT, otherwise the tag value is qos and CTE-LDT must be resumed on CipherTrust Manager. In the example below, GuardPoint /oxf-fs1/gp1 was suspended using voradmin, and it must be resumed after restore using voradmin command.

   voradmin ldt list all
   MDS_1:  type=file, nguards=1, name=/oxf-fs1/gp1/::vorm:mds:: 
       Guard Table: version 1 nentries 1
       Guard 0: type=GP, state=REKEYING SUSPENDED (vadm), flags=GP LOCKED, gp=/oxf-fs1/gp1
               File List: count 4308
   voradmin ldt resume /oxf-fs1/gp1
   

5. Wait for CTE-LDT completion on GuardPoint.

6. We strongly recommend that you disable and re-enable the GuardPoint once more.

The restore is now complete and files in your GuardPoint can be accessed.

The CTE Agent sends the following alert message to CipherTrust Manager if the restore operation is rejected:

LDT-ALERT: Restore of LDT protected file <GuardPoint> not allowed by policy

Potential Warnings During Restore Operation

When using cp for backup/restore, the cp command may report a failed attempt to preserve permissions on the Metadata Store File (MDS) during a restore. If you encounter the below message, continue to proceed with the restore steps since this will not affect the MDS file or dataset that is being restored.

cp: preserving permissions for ‘/oxf-fs1/gp1/::vorm:mds:: ’: Permission denied

When using rsync for backup/restore, the rsync command may report a failed attempt to set extended attribute when restoring the MDS file on system with selinux configured in enforced mode. If user encounters the below message, continue to proceed with the restore steps since this will not affect the MDS file or dataset that is being restored.

rsync: copy_xattrs: lsetxattr(""/oxf-fs1/gp1/::vorm:mds:: "","security.selinux") failed: Permission denied (13)
rsync: rsync_xal_set: lsetxattr(""/oxf-fs1/gp1/::vorm:mds:: "","security.selinux") failed: Permission denied (13)