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

Gregor Kopka (@zfs-discuss) zfs-discuss at kopka.net
Mon Apr 23 05:27:07 EDT 2018


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.zfsonlinux.org/pipermail/zfs-discuss/attachments/20180423/bae93160/attachment.html>


More information about the zfs-discuss mailing list