Encrypting BTRFS Volume
My backups server has a 4 drive BTRFS array (2TB each), and is mounted on /media/backups. Under that are BTRFS subvolumes named for the LAN systems they back up, such as hex, droog, etc. Also under backups is where the snapshots are made, such as hex-snap-2012-10-15, droog-snap-2012-10-15, and so on.
So where can I encrypt? Do I have to go in to each subvolume and make private directories for each of those subdirs like bin, etc, lib, and so on? If so, how would I update the new snapshots which are created, for encryption?
It doesn't seem possible to encrypt a BTRFS subvolume, and certainly not an array?
Quoted 6 lines · On Saturday, December 01, 2012 01:06:59 PM [email protected] wrote:
My backups server has a 4 drive BTRFS array (2TB each), and is mounted on /media/backups. Under that are BTRFS subvolumes named for the LAN systems they back up, such as hex, droog, etc. Also under backups is where the snapshots are made, such as hex-snap-2012-10-15, droog-snap-2012-10-15, and so on.
So where can I encrypt? Do I have to go in to each subvolume and make private directories for each of those subdirs like bin, etc, lib, and so on? If so, how would I update the new snapshots which are created, for encryption?
It doesn't seem possible to encrypt a BTRFS subvolume, and certainly not an array?
Anyone here?
Ecryptfs is not made for volumes. You make a folder that holds your encrypted files. Then you mount it at another location that's in the clear. Perhaps your looking for full-disk encryption instead of filesystem-level encryption. Here's a note from the btrfs wikipedia page:
The current recommendation for encryption with btrfs is to use a full-disk encryption mechanism such as dm-crypt or LUKS on the underlying devices, and to create the btrfs filesystem on top of that layer (and that if a RAID is to be used with encryption, encrypting a dm-raid device or a hardware-RAID device gives much faster disk performance than dm-crypt overlaid by btrfs's own filesystem-level RAID features)
B. J.
Quoted 14 lines · On Mon, Dec 3, 2012 at 9:01 AM, <[email protected]> wrote:
Quoted 6 lines · On Saturday, December 01, 2012 01:06:59 PM [email protected] wrote:
My backups server has a 4 drive BTRFS array (2TB each), and is mounted on /media/backups. Under that are BTRFS subvolumes named for the LAN systems they back up, such as hex, droog, etc. Also under backups is where the snapshots are made, such as hex-snap-2012-10-15, droog-snap-2012-10-15, and so on.
So where can I encrypt? Do I have to go in to each subvolume and make private directories for each of those subdirs like bin, etc, lib, and so on? If so, how would I update the new snapshots which are created, for encryption?
It doesn't seem possible to encrypt a BTRFS subvolume, and certainly not an array?
Anyone here?
--
To unsubscribe from this list: send the line "unsubscribe ecryptfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · B. J. Potter
Ecryptfs is not made for volumes. You make a folder that holds your encrypted files. Then you mount it at another location that's in the clear. Perhaps your looking for full-disk encryption instead of filesystem-level encryption. Here's a note from the btrfs wikipedia page:
Quoted 7 lines
The current recommendation for encryption with btrfs is to use a full-disk encryption mechanism such as dm-crypt or LUKS on the underlying devices, and to create the btrfs filesystem on top of that layer (and that if a RAID is to be used with encryption, encrypting a dm-raid device or a hardware-RAID device gives much faster disk performance than dm-crypt overlaid by btrfs's own filesystem-level RAID features)
That may be on the Wikipedia page, but here's what's in the BTRFS FAQ:
https://btrfs.wiki.kernel.org/index.php/FAQ#Does_btrfs_support_encryption.3F
--------------------------------------------------------------------
Does btrfs support encryption?
No. This is a hard task and easy to do wrong (on a filesystem level). There's nobody actively working on it, although you may have heard it's planned (year 2009), try to understand it like not impossible. Instead, you should use available whole-disk encryption solutions such as dm-crypt or LUKS.
This pretty much forbids you to use btrfs' cool RAID features if you need encryption. Using a RAID implementation on top of several encrypted disks is much slower than using encryption on top of a RAID device. So the RAID implementation must be on a lower layer than the encryption, which is not possible using btrfs' RAID support.
Note: there is an option to use a btrfs internal raid1 for data and metadata: create the filesystem with --mixed option (and DUP profiles), but this may impact performace for volume sizes > 15G (or so).
Another solution is to use stacked encrypting layer like ecryptfs. This does not have the disadvantage mentioned in the paragraph above.
Last but not least it the fuse-based filesystem encfs working as a encrypting layer on top of normal filesystem. Note that the performance may be impacted (dive into fuse details for more). --------------------------------------------------------------------
And this is why I'm here.
OK. Here's an option. Rename your mount /media/encrypted. Make the ecryptfs directory there. Then mount that through ecryptfs as /media/backups. You are necessarily going to lose some btrfs features, here you lose subvolumes. You could set it up differently depending on what features you care about. You might also consider ZFS, which I think is better designed/implemented than BTRFS (but comes with other problems).
As far as ecryptfs goes though. You just make a folder on some device (be it a subvolume, normal filesystem, whatever) and then mount it. Use that wherever you see fit.
Quoted 39 lines · On Mon, Dec 3, 2012 at 10:39 AM, <[email protected]> wrote:
Quoted 6 lines · B. J. Potter
Ecryptfs is not made for volumes. You make a folder that holds your encrypted files. Then you mount it at another location that's in the clear. Perhaps your looking for full-disk encryption instead of filesystem-level encryption. Here's a note from the btrfs wikipedia page:
Quoted 7 lines
The current recommendation for encryption with btrfs is to use a full-disk encryption mechanism such as dm-crypt or LUKS on the underlying devices, and to create the btrfs filesystem on top of that layer (and that if a RAID is to be used with encryption, encrypting a dm-raid device or a hardware-RAID device gives much faster disk performance than dm-crypt overlaid by btrfs's own filesystem-level RAID features)
That may be on the Wikipedia page, but here's what's in the BTRFS FAQ:
https://btrfs.wiki.kernel.org/index.php/FAQ#Does_btrfs_support_encryption.3F
--------------------------------------------------------------------
Does btrfs support encryption?No. This is a hard task and easy to do wrong (on a filesystem level). There's nobody actively working on it, although you may have heard it's planned (year 2009), try to understand it like not impossible. Instead, you should use available whole-disk encryption solutions such as dm-crypt or LUKS.
This pretty much forbids you to use btrfs' cool RAID features if you need encryption. Using a RAID implementation on top of several encrypted disks is much slower than using encryption on top of a RAID device. So the RAID implementation must be on a lower layer than the encryption, which is not possible using btrfs' RAID support.
Note: there is an option to use a btrfs internal raid1 for data and metadata: create the filesystem with --mixed option (and DUP profiles), but this may impact performace for volume sizes > 15G (or so).
Another solution is to use stacked encrypting layer like ecryptfs. This does not have the disadvantage mentioned in the paragraph above.
Last but not least it the fuse-based filesystem encfs working as a encrypting layer on top of normal filesystem. Note that the performance may be impacted (dive into fuse details for more). --------------------------------------------------------------------
And this is why I'm here.
--
To unsubscribe from this list: send the line "unsubscribe ecryptfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 11 lines · B. J. Potter
OK. Here's an option. Rename your mount /media/encrypted. Make the ecryptfs directory there. Then mount that through ecryptfs as /media/backups. You are necessarily going to lose some btrfs features, here you lose subvolumes. You could set it up differently depending on what features you care about. You might also consider ZFS, which I think is better designed/implemented than BTRFS (but comes with other problems).
As far as ecryptfs goes though. You just make a folder on some device (be it a subvolume, normal filesystem, whatever) and then mount it. Use that wherever you see fit.
OK thanks. But subvolumes are critical because we need backup snapshots. And so I am in this mess I have now.
So ecryptfs cannot be applied in my situation, practically.
I don't understand your situation well enough to say (I lack the btrfs subvolume knowledge). The encrypted part of ecryptfs is just a folder of files on your filesystem. You then mount the folder on your system and read/write to that mounted location. The encrypted files are transparently updated as you write to the mounted location. You'll have to apply that information on how ecryptfs works to your situation.
Quoted 8 lines · On Tue, Dec 4, 2012 at 12:05 PM, <[email protected]> wrote:
So ecryptfs cannot be applied in my situation, practically.
--
To unsubscribe from this list: send the line "unsubscribe ecryptfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 7 lines · B. J. Potter
I don't understand your situation well enough to say (I lack the btrfs subvolume knowledge). The encrypted part of ecryptfs is just a folder of files on your filesystem. You then mount the folder on your system and read/write to that mounted location. The encrypted files are transparently updated as you write to the mounted location. You'll have to apply that information on how ecryptfs works to your situation.
A BTRFS subvolume just looks like a subdirectory, except it has special properties to allow BTRFS snapshotting. So I do a backup to /media/backups/droog/root and home, of droog's /root and /home. The first of the month I snapshot the backed-up droog to /media/backups/droog-root-snap-2012-10-01 of the state of the backup on that date, and then I can always go back to that snap for a complete set of backups as of that date. Files aren't duplicated, but are kept track of in a special way by BTRFS.
So /media/backups is my BTRFS volume set of four drives. In order to make snaps, /media/backups/droog (and hex and so on, for my LAN machines) is a subvolume. (which just looks like a subdir) Under backups is droog (current saveset), droog-root-snap-2012-10-01, droog-root-snap-2012-11-01, and so on. So since droog is a subvolume it cannot be encrypted, nor can droog-root-snap-2012-10-01 and so on, because according to the BTRFS FAQ ecryptfs and volumes and subvolumes don't mix. Below droog is root and home, which are regular subdirs and can be encrypted, but they are always snapped to a snap subvolume, and that doesn't seem possible since it would be bridging over BTRFS accounting.
If the only use of subvolumes is for snapshotting, it seems to me that you could make one subvolume contain the encrypted directory, and then take snapshots of the encrypted directory/subvolume instead of taking snapshots of the unencrypted volume.
Otherwise, it appears that you're going to lose one of {encryption, BTRFS RAID and snapshotting}, which suggests to me that you should evaluate the trade-offs between this approach and just using ext4+dm-crypt+lvm.
Quoted 18 lines · On Wed, Dec 5, 2012 at 10:48 AM, <[email protected]> wrote:
Quoted 7 lines · B. J. Potter
I don't understand your situation well enough to say (I lack the btrfs subvolume knowledge). The encrypted part of ecryptfs is just a folder of files on your filesystem. You then mount the folder on your system and read/write to that mounted location. The encrypted files are transparently updated as you write to the mounted location. You'll have to apply that information on how ecryptfs works to your situation.
A BTRFS subvolume just looks like a subdirectory, except it has special properties to allow BTRFS snapshotting. So I do a backup to /media/backups/droog/root and home, of droog's /root and /home. The first of the month I snapshot the backed-up droog to /media/backups/droog-root-snap-2012-10-01 of the state of the backup on that date, and then I can always go back to that snap for a complete set of backups as of that date. Files aren't duplicated, but are kept track of in a special way by BTRFS.
So /media/backups is my BTRFS volume set of four drives. In order to make snaps, /media/backups/droog (and hex and so on, for my LAN machines) is a subvolume. (which just looks like a subdir) Under backups is droog (current saveset), droog-root-snap-2012-10-01, droog-root-snap-2012-11-01, and so on. So since droog is a subvolume it cannot be encrypted, nor can droog-root-snap-2012-10-01 and so on, because according to the BTRFS FAQ ecryptfs and volumes and subvolumes don't mix. Below droog is root and home, which are regular subdirs and can be encrypted, but they are always snapped to a snap subvolume, and that doesn't seem possible since it would be bridging over BTRFS accounting.
--
To unsubscribe from this list: send the line "unsubscribe ecryptfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 5 lines
Thanks, Michael Chang 3B Software Engineering (Class of 2014) University of Waterloo
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 2 lines · On Tuesday, December 04, 2012 10:04:18 AM [email protected] wrote:
So ecryptfs cannot be applied in my situation, practically.
I get it. encryption cannot be done if snapshots.
Disappointing.
I don't think that is true _per se_.
I do believe encryption can be theoretically done with snapshots, I'm just not sure how to do so in a way that's meaningfully safe.
I'm still of the impression that btrfs on top of whole-disk encryption (dm-crypt) is the best way to go here.
Quoted 11 lines · On Mon, Dec 10, 2012 at 5:23 PM, <[email protected]> wrote:
Quoted 2 lines · On Tuesday, December 04, 2012 10:04:18 AM [email protected] wrote:
So ecryptfs cannot be applied in my situation, practically.
I get it. encryption cannot be done if snapshots.
Disappointing.
--
To unsubscribe from this list: send the line "unsubscribe ecryptfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 5 lines
Thanks, Michael Chang 3B Software Engineering (Class of 2014) University of Waterloo
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): CAHcyQ+7UeWtYmfNFOMp6zuqVN=K2o=ebyhGuOAPDF5-oEBFU+w@mail.gmail.com
Not too worried about the workload because this is just a backups server.
But I don't understand the structure you're suggesting. Can you explain?
Quoted 23 lines · you
If you haven't changed the data before encryption, eCryptFS won't change the backing file.
Deduping will probably be less efficient because a small change in a large file could cause a larger part (maybe the whole) file to change, but on a per-file basis you shouldn't see that much difference.
It'll depend on your exact workload, though.
Quoted 9 lines · On Thu, Dec 6, 2012 at 4:28 PM, <[email protected]> wrote:
Quoted 4 lines · you
If the only use of subvolumes is for snapshotting, it seems to me that you could make one subvolume contain the encrypted directory, and then take snapshots of the encrypted directory/subvolume instead of taking snapshots of the unencrypted volume.
So the array is /media/backups and subvolumes are /media/backups/droog, droog-snap-{date}, /media/backups/hex, hex-snap-{date}, etc. The subvolumes and snaps have a special BTRFS relationship which eliminates dupes, and what I don't know is if ecryptfs would interfere with that. Seems like it would.