|
The use cases for encrypted files backup/restore we want to address are:
- backup/restore of MDT and OST directly at the ldiskfs level, to be able to migrate to a newly-formatted MDT or OST filesystem.
In this case we are considering the use of a patched tar to carry out specific operations if an encrypted file is detected. This consequently requires that encrypted files are properly flagged at the ldiskfs level.
- backup/restore of regular files at the Lustre client level, without the encryption key so that no clear text copy of encrypted files are made.
Again in this case we are considering the use of a modified tar that would carry out specific operations on encrypted files, and passing the O_FILE_ENC | O_DIRECT flags to be able to access to raw content without the encryption key.
- Lustre/HSM without the encryption key so that no clear text copy of encrypted files are made.
This will consist in adjusting the lhsmtool_posix utility's behavior for encrypted files.
We are considering the use of a 'virtual' xattr named for instance "security.encdata". Fetching or setting this xattr would have a special meaning for llite and ldiskfs, and this xattr could be filled with useful information such as clear text size (or preferably a delta between encrypted file size and clear text file size in order to save space in the xattr), encryption context and encrypted name. Setting this security.encdata xattr will be limited to the case when the file does not have an encryption context yet, to avoid users changing the encryption context after a file is created.
For testing and development purposes, we want to create a new lfs command to trigger backup and restore on Lustre files whose path is given as input. That will leverage the internal mechanisms mentioned above, and could also be used as-is for specific workflows such as moving encrypted files between file systems without decrypt/encrypt.
|
HLD_backup_restore_enc_files_v0.3.pdf