my last contribution to this thread (and there was much rejoicing!) Miles Nordin wrote: >>>>>> "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.
Disagree. Archives tend to not be overwritten, ever. Backups have all sorts of management schemes to allow the backup media to be reused. > 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 > Bzzt. Thanks for playing. That is: re> CR 6764193 was fixed in b105 re> http://bugs.opensolaris.org/view_bug.do?bug_id=6764193 Is re> there another? -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
