>>>>> "mp" == Mattias Pantzare <[EMAIL PROTECTED]> writes:
mp> Or the file was corrupted when you transfered it.
he stored the backup streams on ZFS, so obviously they couldn't
possibly be corrupt. :p
Jonathan, does 'zfs receive -nv' also detect the checksum error, or is
it only detected when you actually receive onto a pool without -n?
in addition to skipping to the next header of corrupted tarballs, tar
can validate a tarball's checksums without extracting it, so it's
possible to write a tape, then read it to see if it's ok. The 'tar t'
read test checks for medium errors, driver bugs, and bugs inside tar
itself.
so it sounds like: brrk, brrk, danger, do not use zfs send/receive for
backups---use only for moving filesystems from one pool to another.
This brings back the question ``how is it possible to back up and
restore a heavily-cloned/snapshotted system?'' because upon restore
the clone inheritance tree is lost, and you'll never have enough space
in the pool to fit what was there before.
pgpKRGlG0Pbzz.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
