>>>>> "c" == Miles Nordin <car...@ivy.net> writes: >>>>> "mg" == Mike Gerdts <mger...@gmail.com> writes:
c> are compatible with the goals of an archival tool:
sorry, obviously I meant ``not compatible''.
mg> Richard Elling made an interesting observation that suggests
mg> that storing a zfs send data stream on tape is a quite
mg> reasonable thing to do. Richard's background makes me trust
mg> his analysis of this much more than I trust the typical person
mg> that says that zfs send output is poison.
ssh and tape are perfect, yet whenever ZFS pools become corrupt
Richard talks about scars on his knees from weak TCP checksums and
lying disk drives and about creating a ``single protection domain'' of
zfs checksums and redundancy instead of a bucket-brigade of fail of
tcp into ssh into $blackbox_backup_Solution(likely involving
unchecksummed disk storage) into SCSI/FC into ECC tapes. At worst,
lying then or lying now? At best, the whole thing still strikes me as
a pattern of banging a bunch of arcania into whatever shape's needed
to fit the conclusion that ZFS is glorious and no further work is
requried to make it perfect.
and there is still no way to validate a tape without extracting it,
which is last I worked with them, an optional but suggested part of
$blackbox_backup_Solution (and one which, incidentally, helps with the
bucket brigade problem Richard likes to point out).
and the other archival problems of constraining the restore
environment, and the fundamental incompatibility of goals between
faithful replication and robust, future-proof archiving from my last
post.
pgpLLsyZQuSKJ.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
