>>>>> "re" == Richard Elling <richard.ell...@gmail.com> writes:
re> The reason is that zfs send/recv has very good application,
re> even in the backup space. There are, in fact, many people
re> using it.
[...]
re> ZFS send is not an archival solution. You should use an
re> archival method which is appropriate for your business
re> requirements. Note: "method" above, not product or command.
well, I think most backups are archival. If we start arguing about
words, I think everyone's lost interest long ago. But I do think to
protect oneself from bad surprises it would be good to never archive
the output of 'zfs send', only use it to move data from one place to
another.
yes, backup ``method'', moving data from one place to another is often
part of backup and can be done safely with 'zfs send | zfs recv', but
without a specific warning people will imagine something's safe which
isn't, when you say the phrase ``use zfs send for backup''.
re> CR 6764193 was fixed in b105
>> I read someone ran into it when importing a pool, too, not just
>> when using 'zfs send'. so hopefully that fix came for free at
>> the same time.
re> Perhaps your memory needs to be using checksum=sha256 :-) I do
re> not recall such a conversation or bug.
fine, here you go:
http://mail.opensolaris.org/pipermail/zfs-discuss/2008-December/053894.html
pgpT0KCeNBuJQ.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
