I'm trying to create an encrypted data folder which could periodically take snapshots of the current state of it. The snapshot should be an encrypted one, and I should be able to take snapshots without "unmounting" the encrypted folder. Is this possible?

It seems like I could encrypt folders with EncFS, eCryptfs and gocryptfs, but I did not find wether I could take snapshots of the encrypted files while the folder is mounted. Using full disk encryption with btrfs is not an option (if it even is possible).

  • Side note, just to be sure you're aware: snapshots outside the encryption layer allow various traffic-analysis-like attacks. E.g., by comparing two snapshots, determine when an encrypted file is typically edited, or when last edited, or how often edited, etc. More interestingly, which are typically changed around the same time (depending on how frequent the snapshots are) — this may allow figuring out what some files are, even when the names are encrypted. Also, if block-based encryption, figuring out which blocks have changed — so knowing which part of the file was edited.
    – derobert
    Oct 7 '19 at 17:51
  • ... some of these are available anyway if your encrypted filesystem exposes metadata. And for low enough snapshot frequencies or privacy requirements it may not matter. Just want to make sure you're aware there are potential privacy drawbacks, especially if you're considering frequent snapshots.
    – derobert
    Oct 7 '19 at 17:52
  • derobert, Yeah I'm aware of that drawback, however, the privacy requirements for my application are not that strict, so traffic-analysis-attacks are not a concern. Oct 8 '19 at 8:14

It is certainly possible, in one way or another.

I do this wiht an image file, two layers of file system (ZFS), and one layer of dm-crypt. The setup is easy to describe: Put a snapshot-capable and transaction-resistent filesystem on the image file, put a new image file on that filesystem. Make an encrypted block device of that file with cryptsetup. Create a new filesystem on that block device, and mount it at a convenient place.

The unencrypted filesystem can now be snapshot and the image file with the encrypted filesystem can be saved from this snapshot.

The file systems must be transaction-resitant, in case the snapshot happens at an inconvenient time. The unfinished transactions will be ignored and a consistent version of the files should result. There is still some technical complication with ordering if multiple files are updated though (which I'm not qualified to explain) so a database might be upset at the result. I think nilfs2 has a configuration option to use strict syncing in this case, if that is important.

In practice there are many complicated and fail-prone steps to set up and tear down this, so elaborate and fail-resistent scripts with proper testing of what has already been done/undone are recommended. I use zfs because it is easy to manage, and simplifies this task.

  • Thank you! When pondering it in my mind it might be exactly what I need here. However, the part "Put a snapshot-capable and transaction-resistent filesystem on the image file, put a new image file on that filesystem" makes me wonder whether I understand it correctly or not; do you mean to create an image file with and unecnrypted ZFS partition inside it, and inside that partition create another image file with encrypted ZFS partition? If I understood correctly, the ZFS snapshot needs to be taken of the underlying encrypted ZFS partition? Oct 9 '19 at 12:46
  • Also, once I take a snapshot, can the snapshot data be compressed so not all snapshots are the size of the image file? Oct 9 '19 at 12:47
  • Yes, the first filesystem is just to make snapshots (of the encrypted image file used for the real filesystem). ZFS does not have encryption, so that's why I use dm-crypt to create a block device on top of that image file. The image file would look like random data and compress porly, I'm afraid. Oct 9 '19 at 13:55
  • Hm, what are you going to do with the snapshots? I assumed you were going to move them somewhere, but if all you want is to keep a history of changes, all you need is an imagefile, dm-crypt, and zfs on top of that. Everything in the zfs will be encrypted at the physical disk level, including the snapshots. Oct 9 '19 at 14:02
  • My intention is to store the snapshots, i.e. upload them to the "cloud". Maybe using image files is not the way to go after all if they cannot be compressed/are not dynamically resizeable.. Oct 9 '19 at 14:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.