>>>>> "mm" == Michael McKnight <michael_mcknigh...@yahoo.com> writes:
mm> #split -b8100m ./mypictures.zfssnap mypictures.zfssnap.split.
mm> #cat mypictures.zfssnap.split.a[a-g] > testjoin
mm> But when I compare the checksum of the original snapshot to
mm> that of the rejoined snapshot, I get a different result:
sounds fine. I'm not sure why it's failing.
mm> And when I try to restore the filesystem, I get the following
mm> failure: #zfs recv pool_01/test < ./testjoin cannot receive
mm> new filesystem stream: invalid stream (checksum mismatch)
however, aside from this problem you're immediately having, I think
you should never archive the output of 'zfs send'. I think the
current warning on the wiki is not sufficiently drastic, but when I
asked for an account to update the wiki I got no answer. Here are the
problems, again, with archiving 'zfs send' output:
* no way to test the stream's integrity without receiving it.
(meaning, to test a stream, you need enough space to store the
stream being tested, plus that much space again. not practical.)
A test could possibly be hacked up, but because the whole ZFS
software stack is involved in receiving, and is full of assertions
itself, any test short of actual extraction wouldn't be a thorough
test, so this is unlikely to change soon.
* stream format is not guaranteed to be forward compatible with new
kernels. and versioning may be pickier than zfs/zpool versions.
* stream is expanded _by the kernel_, so even if tar had a
forward-compatibility problem, which it won't, you could
hypothetically work around it by getting an old 'tar'. For 'zfs
send' streams you have to get an entire old kernel, and boot it on
modern hardware, to get at your old stream.
* supposed to be endian-independent, but isn't.
* stream is ``protected'' from corruption in the following way: if a
single bit is flipped anywhere in the stream, the entire stream and
all incrementals descended from it become worthless. It is
EXTREMELY corruption-sensitive. 'tar' and zpool images both
detect, report, work around, flipped bits. The 'zfs send' idea is
different: if there's corruption, the designers assume you can just
restart the 'zfs send | zfs recv' until you get a clean go---what
you most need is ability to atomically roll back the failed recv,
which you do get. You are not supposed to be archiving it!
* unresolved bugs. ``poisonous streams'' causing kernel panics when
you receive them,
http://www.opensolaris.org/jive/thread.jspa?threadID=81613&tstart=0
The following things do not have these problems:
* ZFS filesystems inside file vdev's (except maybe the endian
problem. and also the needs-whole-kernel problem, but mitigated by
better forward-compatibility guarantees.)
* tar files
In both alternatives you probably shouldn't use gzip on the resulting
file. If you must gzip, it would be better to make a bunch of tar.gz
files, ex., one per user, and tar the result. Maybe I'm missing some
magic flag, but I've not gotten gzip to be too bitflip-resilient.
The wiki cop-out is a nebulous ``enterprise backup ``Solution' ''.
Short of that you might make a zpool in a file with zfs compression
turned on and rsync or cpio or zfs send | zfs recv the data into it.
Or just use gtar like in the old days. With some care you may even be
able to convince tar to write directly to the medium. And when you're
done you can do a 'tar t' directly from medium also, to check it. I'm
not sure what to do about incrementals. There is a sort of halfass
incremental feature in gtar, but not like what ZFS gives.
pgpwUYXwCkuVI.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
