Encrypting BTRFS Volume

Encrypting BTRFS Volume

[CACook]

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?
 
 

Re: Encrypting BTRFS Volume

[CACook]

On Saturday, December 01, 2012 01:06:59 PM CACook@quantum-sci.com 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?

Re: Encrypting BTRFS Volume

[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:

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.

On Mon, Dec 3, 2012 at 9:01 AM,  <CACook@quantum-sci.com> wrote:
> On Saturday, December 01, 2012 01:06:59 PM CACook@quantum-sci.com 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Encrypting BTRFS Volume

[CACook]

On Monday, December 03, 2012 07:41:09 AM B. J. Potter wrote:
> 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)

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.

Re: Encrypting BTRFS Volume

[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.

On Mon, Dec 3, 2012 at 10:39 AM,  <CACook@quantum-sci.com> wrote:
> On Monday, December 03, 2012 07:41:09 AM B. J. Potter wrote:
>> 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)
>
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Encrypting BTRFS Volume

[CACook]

On Monday, December 03, 2012 09:04:38 AM B. J. Potter wrote:
> 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.

Re: Encrypting BTRFS Volume

[CACook]

So ecryptfs cannot be applied in my situation, practically.

Re: Encrypting BTRFS Volume

[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.

On Tue, Dec 4, 2012 at 12:05 PM,  <CACook@quantum-sci.com> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Encrypting BTRFS Volume

[CACook]

On Tuesday, December 04, 2012 06:46:11 PM B. J. Potter wrote:
> 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.
 
 

Re: Encrypting BTRFS Volume

[Michael Chang]

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.

On Wed, Dec 5, 2012 at 10:48 AM,  <CACook@quantum-sci.com> wrote:
> On Tuesday, December 04, 2012 06:46:11 PM B. J. Potter wrote:
>> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks,

Michael Chang
3B Software Engineering (Class of 2014)
University of Waterloo

Re: Encrypting BTRFS Volume

[CACook]

On Tuesday, December 04, 2012 10:04:18 AM CACook@quantum-sci.com wrote:
> 
> So ecryptfs cannot be applied in my situation, practically.

I get it.  encryption cannot be done if snapshots. 
 
Disappointing.

Re: Encrypting BTRFS Volume

[Michael Chang]

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.

On Mon, Dec 10, 2012 at 5:23 PM,  <CACook@quantum-sci.com> wrote:
> On Tuesday, December 04, 2012 10:04:18 AM CACook@quantum-sci.com 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks,

Michael Chang
3B Software Engineering (Class of 2014)
University of Waterloo

Re: Encrypting BTRFS Volume

[CACook]

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?


On Thursday, December 06, 2012 02:18:45 PM you wrote:
> 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.
> 
> On Thu, Dec 6, 2012 at 4:28 PM,  <CACook@quantum-sci.com> wrote:
> >
> > On Wednesday, December 05, 2012 03:39:03 PM you wrote:
> >> 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.
> >
> 
> 
> 
>