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 LDT is in progress over GuardPoints poses some challenges when files in GuardPoints are backed up in an encrypted format. The challenge with this method of backup is the existence of the CTE-LDT Metadata Store file (MDS) in the GuardPoint during the backup or restore process, and strict protection enforced on MDS files preventing deletion or modification to MDS files.

Secondly, your backup utility must backup and restore extended attributes of files and the GuardPoint directory. Because CTE-LDT extended attributes are also protected similarly to MDS files, your backup must be enabled to restore extended attributes for files. To overcome both restrictions, your policy on the GuardPoint must include a security rule without Apply Key Effect to enable your backup utility to replace MDS files, and CTE-LDT extended attributes for files, as part of backup/restore operations. Additionally, your backup utility must be signed with a signature set from 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 a GuardPoint namespace cannot be backed up or restored using this method of backup.

You must suspend CTE-LDT on GuardPoint before performing a 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

You cannot restore to a GuardPoint during LDT, even after suspending LDT. Restoring to a GuardPoint in rekeying state will result in loss of data and potentially, data corruption. Follow the steps below to perform a full level restore of the GuardPoint.

Restoring a GuardPoint from a Backup

To properly restore GuardPoints along with the MDS file:

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

2. Once restore is complete, the GuardPoint needs to be disabled and enabled again. For manual GuardPoint, run the secfsd command as shown below. For auto-guards, disable and enable GuardPoints on CipherTrust Manager.

   # secfsd -unguard <${gp}>
   # secfsd -guard <${gp}>
   

3. Disabling GuardPoint will remove the MDS file restored to the GuardPoint and flag the GuardPoint for RELAUNCH to restart LDT. Although the restored MDS file includes critical metadata for execution of LDT, the restored file does not hold data for any files in partial rekeyed status at the time the MDS file is restored. As such, the restored MDS file is automatically removed when GuardPoint is disabled. Once the GuardPoint is enabled, LDT is automatically relaunched on the GuardPoint as the result of RELAUNCH flag. Relaunching LDT will encrypt every file to the latest key version under LDT 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)