>>>>> "da" == David Abrahams <[EMAIL PROTECTED]> writes:
da> Is there a cheaper alternative that will securely and
da> persistently store a copy of my data offsite?
rented dedicated servers with disks in them? I have not shopped for
this, but for backups it just needs to not lose your data at the same
time as the primary copy, not the same quality level as needing to
really for certain save the data no matter what.
da> tar actually adds redundancy to the degree that it could
da> detect and correct bit flips?
no, of course not. but the following formats:
* tar/cpio
* zpool on disk
* other filesystems (ufs, xfs, ext3, hfs+, iso9660, ...)
All have the characteristic that a flipped bit will usually not affect
much---almost always just one file, or sometimes a little more if it's
metadata. Maybe a really small number of bits are extremely special
because of filesystem bugs, but experience and hard lessons keeps
these minimal.
OTOH, If one bit of a zfs send stream is flipped, you are guaranteed
to lose the ENTIRE stream.
to review, the problems with storing zfs send output are:
* the one we just discussed
* endiness/zfs-version unportability
* lack of validation tool like 'tar t' or 'zpool scrub'
tar files and (mostly) zpool-inside-mkfile do not have these problems.
da> Hmm... not much good for incremental backups, though.
right, that's a big problem. esp with slow zfs send and S3's
copyin/copyout fees. I've no answer.
da> Also, it will replicate all the redundant data in snapshots
da> and clones
no, zfs send | zfs recv will recreate the same clone tree on the
mkfile-zpool.
pgpL8VbVVhnRn.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
