[zfs-discuss] Secure offsite backup on untrusted remote storage without loosing the benefits of ZFS

Kuba kuba.0000 at op.pl
Mon Feb 22 05:06:01 EST 2016

W dniu 2016-02-19 o 14:49, Schweiss, Chip pisze:
> On Sun, Feb 14, 2016 at 4:45 PM, Durval Menezes via zfs-discuss
> <zfs-discuss at list.zfsonlinux.org
> <mailto:zfs-discuss at list.zfsonlinux.org>> wrote:
>     Hello Kuba,
>     On Sun, Feb 14, 2016 at 7:44 PM, Kuba via zfs-discuss
>     <zfs-discuss at list.zfsonlinux.org
>     <mailto:zfs-discuss at list.zfsonlinux.org>> wrote:
>         I'm trying to find a proper way to make encrypted, offsite
>         backups of ZFS datasets on untrusted remote server(s) over the
>         Internet without loosing the functionality of the ZFS itself.
>         Functionality-wise I'd like to achieve something like this:
>         1) Open 2 sessions to iSCSI targets on 2 remote servers in 2
>         locations
>         2) Use the corresponding block devices to locally create 2 LUKS
>         volumes
>         3) Create a mirrored backup pool on top of these volumes
>         Now you have a secure, redundant, remote backup pool and you can
>         send/receive (incremental) replication streams, make snapshots
>         and clones, mount remote backups locally etc. while ZFS is
>         taking care about data integrity and redundancy. You could even
>         scrub the backup pool. These are the "benefits of ZFS" that I
>         wouldn't want to loose and - what's most important - all of that
>         is possible without any single byte leaving your site unencrypted.
>     This is very similar to what I've been doing here for the last 3
>     years or so.
>         Unfortunately, that kind of setup is not particularly fast. To
>         put it in context, lets assume we're dealing with ADSL
>         connection (1-2Mbps uplink, pings around 50ms), backup pool has
>         ~50GB (scrubs...) and daily incremental backups require updating
>         ~1GB of data.
>     This can be easily solved by replacing your ADSL connection by a
>     1Gbps FiOS or similar ;-)
>     Seriously now, ZFS can't do (that much) magic. If all you have is a
>     slow ADSL connection, then replication is going to be slow. Perhaps
>     you could compress the ZFS send.receive stream (if your replicated
>     data isn't heavily compressed), but don't expect any miracles.
> I would do this by running a remote ZFS server to receive snapshot.
> Trying to remote mount iSCSI is asking for troubles.
> So long as you have enough bandwidth to keep up with your zfs sends
> there are tools that can keep the pipe full.   I use BBCP to pipe my ZFS
> sends across long distances and maximize my throughput.   It adds
> buffering and multiple connections to the flow.
> With the recent addition of resumable snapshots this is even easier than
> it used to be, especially on your initial send.
> Putting ZFS on top of encrypted volumes is also trivial.   Protecting
> your keys is a little less trivial.

If I understand you correctly, that would require executing "zfs 
receive" on the remote server, which means the backup pool would have to 
be imported on that server at least for the duration of "zfs reveive" 
command - all of which is typical for a straightforward remote stream 
replication, but that also means there would have to be a way to decrypt 
my data on the remote site, which is precisely what I want to avoid :( I 
just don't trust the remote server.

But maybe some day ZFS will support full homomorphic encryption...
Imagine that :)

Best regards,

> -Chip
>     Cheers,
>     --
>         Durval.
>         Is there any better solution that would achieve better
>         performance without sacrificing the following goals?
>         The goals are:
>           - a must-have: data safety (local encryption) and integrity
>         (checksums)
>           - a nice-to-have: ZFS benefits
>           - a little wish: reasonable data throughput
>         I'll be very grateful for any ideas.
>         Best regards,
>         Kuba

More information about the zfs-discuss mailing list