Re: send/receive for encrypted backup purposes

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2016-01-08 08:44, Martin Steigerwald wrote:
> Hi!
>
> Given that the Omnia Turris router has an mSATA slot and two USB 3 connectors,
> I am pondering the feasibility for using it for backups of my home dir.
>
> I pondered checking out zbackup, attic or obnam for that, of which at least
> zbackup and obnam can do encrypted backups¹²³.
>
> Yet then I thought why not using btrfs send and receive directly? I found two
> answers:
>
> Client doesn´t encrypt. And even tough I think the Omnia will be pretty secure
> unless I configure a hole into it, I´d not feel that comfortable putting my
> whole home directory there unsecured.
>
> So my question is, would it be possible to have btrfs send/receive encrypted?
> So far I have only three ideas about it, the first two are similar:
>
> 1) Mount a dm-crypted loopback file formatted with BTRFS from the router on
> the client. Of course dm-crypt stuff need to happen on the client then. And I
> wonder whether I would loose most of the probably performance benefit of using
> btrfs send/receive this way. I could export the file with nfs for example.
This really depends on what you are using it for, and how it's 
configured.  In the case of the backup side, I wouldn't worry as much 
about performance, as backups are ideally write once, read once 
(assuming you verify them that is), and therefore aren't really 
performance critical.  If you can get the router set up with dm-crypt, 
you could transfer the send stream over SSH (or something similar) and 
avoid some of the networking overhead.
>
> 2) Export a block device from the Omnia directly wie NBD or iSCSI or whatnot
> and use it with dm-crypt on the client.
This is probably your best bet as far as efficiency goes.  In general, 
I'd recommend NBD over iSCSI for this type of thing, as it's a lot more 
lightweight (and thus more efficient in most respects).  If you only 
ever need to access the device locally on the network served by the 
router however, I'd actually suggest ATAoE over iSCSI or NBD, it's a lot 
more efficient and technically more secure because it's non-routable (it 
runs directly over the link layer, which means you avoid the overhead of 
IP and TCP, and has the added advantage that you technically don't need 
anything but the kernel driver on the client side).
>
> 3) Have all home directories crypted via ecryptfs and only send/receive the
> subvolumes with the ecryptfs files.
This would work, but has the potential to be highly error prone, and 
likely very inefficient (at least, as compared to either of the above 
options).  There's also small amounts of metadata that get inherently 
leaked by using in-line encryption at the VFS layer (the impact of this 
is small for most people, but should still be considered).
>
>
> Any other ideas?
>
>
> Something like this would also be nice to have to store on cloud storage.
> Something along the line to send a crypted btrfs send/receive stream. Ideally
> target could be a directory on some storage that doesn´t even need to be a
> BTRFS. But I bet that would be a lot of work to implement.
>
This actually isn't all that hard to do.  The send stream can be stored 
just fine as a flat file on your target system, and thus can easily be 
compressed and/or encrypted.  This is actually what I used to do before 
I realized that incremental backups were saving me absolutely no time, 
and almost no space.  (I've actually switched to using SquashFS for 
backup storage, as it's space efficient, and has the added advantage 
that I can directly boot my backups to use as a recovery environment).

There's not anything I know of that actually does this, but it wouldn't 
be hard to write software to automate it.  Keep in mind that storing 
data that way is less efficient than receiving the stream directly onto 
another FS, but I doubt that that will have much practical impact, and 
you can mitigate this by being selective about what you back up.