[zfs-discuss] cannot import 'home': I/O error Destroy and re-create the pool from a backup source

John Covici covici at ccs.covici.com
Mon Apr 23 07:00:10 EDT 2018


But does not syncoid/sanoid use zfs recv -f ?  I am pretty sure I saw
the -f switch in syncoid.

I do the data sets individually, so I think I should be OK, but its an
interesting question.

On Mon, 23 Apr 2018 05:27:07 -0400,
Gregor Kopka (@zfs-discuss) via zfs-discuss wrote:
> 
> [1  <multipart/alternative (7bit)>]
> [1.1  <text/plain; utf-8 (8bit)>]
> [1.2  <text/html; utf-8 (8bit)>]
> Using zfs send -R/-p will send a replication stream (-p triggers this quite unexpected: https://github.com/zfsonlinux/zfs/issues/5341) that when being combined with zfs recv -F removes snapshots outside of the range you gave to zfs send
> -i/-I and even child datasets (should they be removed on the source) from the destination - snapshots and datasets that you most likely wanted to keep for the case that something went wrong on the source.
> 
> It's good security practice to pull backups (so a compromised source can't modify/destroy them), but zfs send -R/-p | recv -F allows the source to manipulate the destination outside the -i/-I window you might expect (even affect child
> datasets using send -R). For example sending an empty dataset (instead of the data that just had been there) with -R will destroy the whole dataset hirarchy pointed to by the zfs recv -F (as this will turn the destination into what
> currently is on the source: an empty dataset without children). Basically an extended version of https://github.com/zfsonlinux/zfs/issues/1575 that will happily destroy data you might want to keep.
> 
> Not having -F on the recv massively limits what the received data stream can do to your datasets. You'll still have to make sure that your backup system can't be compromised through zfs send -p (like overloading a critical system
> directory with a filesystem containing attacker controlled configuration), for example by mounting the backup destination pool with -R (leads to the contained datasets being constrained to below the specified mountpoint).
> 
> TL;DR: Don't use zfs recv -F for (automated) backup.
> 
> Gregor
> 
> Am 22.04.2018 um 22:27 schrieb Anton Gubar'kov via zfs-discuss:
> 
>  To clarify a bit, the datasets in the pool have a lot of snapshots already via autosnapshot feature, so no new snapshots are required for sending. I would be able to send to another host with zfs over the net and/or via a usb
>  connected drive with zfs once I can import the pool.
> 
>  Anton. 
> 
>  В Вс, 22/04/2018 в 22:23 +0200, Daniel Armengod via zfs-discuss пишет:
> 
>  Hi Gregor,
> 
> Why is zfs send a potentially dangerous operation? If the pool was
> imported with -o readonly, and you can send the filesystem without
> snapshotting it first, does it introduce extra risk vs dd-ing the whole
> drive away? I'm assuming the stream is sent to a machine over the network.
> 
> Daniel
> 
> On 2018-04-21 22:57, Gregor Kopka (@zfs-discuss) via zfs-discuss wrote:
> 
>  
> As a note for after the problem has been solved: Never use zfs send
> -R/-p or zfs recv -F when dealing with backups (as these are able to
> destroy more than you want).
> 
> Gregor
> 
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at list.zfsonlinux.org
> http://list.zfsonlinux.org/cgi-bin/mailman/listinfo/zfs-discuss
> 
> 
> 
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at list.zfsonlinux.org
> http://list.zfsonlinux.org/cgi-bin/mailman/listinfo/zfs-discuss
> 
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at list.zfsonlinux.org
> http://list.zfsonlinux.org/cgi-bin/mailman/listinfo/zfs-discuss
> 
> [2  <text/plain; utf-8 (base64)>]
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at list.zfsonlinux.org
> http://list.zfsonlinux.org/cgi-bin/mailman/listinfo/zfs-discuss

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici wb2una
         covici at ccs.covici.com


More information about the zfs-discuss mailing list