All of lore.kernel.org
 help / color / mirror / Atom feed
From: CACook@quantum-sci.com
To: ecryptfs@vger.kernel.org
Subject: Re: Encrypting BTRFS Volume
Date: Wed, 5 Dec 2012 07:48:36 -0800	[thread overview]
Message-ID: <201212050748.36206.CACook@quantum-sci.com> (raw)
In-Reply-To: <CACDOv80NnYPfy23JXLK9_RhdHw5_z+SC7bWhuy_B-FscGQEY4Q@mail.gmail.com>

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.
 
 

  reply	other threads:[~2012-12-05 15:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-01 21:06 Encrypting BTRFS Volume CACook
2012-12-03 15:01 ` CACook
2012-12-03 15:41   ` B. J. Potter
2012-12-03 16:39     ` CACook
2012-12-03 17:04       ` B. J. Potter
2012-12-03 17:56         ` CACook
2012-12-04 18:05           ` CACook
2012-12-05  2:46             ` B. J. Potter
2012-12-05 15:48               ` CACook [this message]
2012-12-05 23:39                 ` Michael Chang
     [not found]           ` <201212041004.18477.CACook@quantum-sci.com>
2012-12-10 22:23             ` CACook
2012-12-11  1:51               ` Michael Chang
     [not found] ` <201212061328.15342.CACook@quantum-sci.com>
     [not found]   ` <CAHcyQ+7UeWtYmfNFOMp6zuqVN=K2o=ebyhGuOAPDF5-oEBFU+w@mail.gmail.com>
2012-12-06 22:34     ` CACook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201212050748.36206.CACook@quantum-sci.com \
    --to=cacook@quantum-sci.com \
    --cc=ecryptfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.