zfs receive has no error recovery and what that implies
zfs send' and '
zfs receive' are a great thing about
ZFS. They give you easy, efficient, and reliable replication of ZFS
filesystems, which is good for both backups and transfers (and
testing). The combination is among my favorite
ways of shuffling filesystems around, right up there with
restore and ahead of
rsync. But there is an important caveat
zfs receive that deserves to be more widely known, and that
zfs receive makes no attempt to recover from a partially
damaged stream of data.
Formats and programs like
restore, and so on generally
have provisions for attempting to skip over damaged sections of the
stream of data they're supposed to restore. Sometimes this is
explicitly designed into the stream format; other times the programs
just use heuristics to try to re-synchronize a damaged stream at
the next recognizable object. All of these have the goal of letting
you recover at least something from a stream that's been stored and
damaged in that storage, whether it's a tarball that's experienced
some problems on disk or a
dump image written to tape and now the
tape has a glitch.
zfs receive does not do any of this. If your stream is damaged
in any way,
zfs receive aborts completely. In order to recover
anything at all from the stream, it must be perfect and completely
undamaged. This is generally okay if you're directly feeding a '
send' to '
zfs receive'; an error means something bad is going
on, and you can retry the send immediately. This is not good if you
are storing the '
zfs send' output in a file before using '
receive'; any damage or problem to the file, and it's completely
unrecoverable and the file is useless. If the '
zfs send' file is
your only copy of the data, the data is completely lost.
There are some situations where this lack of resilience for saved
send streams is merely annoying. If you're writing the '
output to a file on media as a way of transporting it around and
the file gets damaged, you can always redo the whole process (just
as you could redo a '
zfs send | zfs receive' pipeline). But in
other situations this is actively dangerous, for example if the
file is the only form of backup you have or the only copy of the
data. Given this issue I now strongly discourage people from storing
zfs send' output unless they're sure they know what they're doing
and they can recover from restore failures.
I doubt that ZFS will ever change this behavior, partly because it
would probably require a change in the format of the send/receive
data stream. My impression is that ZFS people have never considered
it a good idea to store '
zfs send' streams, even if they never
said this very strongly in things like documentation.
(You also wouldn't want continuing to be the default behavior for '
receive', at least in normal use. If you have a corrupt stream and you
can retry it, you definitely want to.)
Comments on this page:Written on 07 May 2017.