Miles Nordin wrote: >>>>>> "re" == Richard Elling <richard.ell...@gmail.com> writes: >>>>>> > > re> Indeed, but perhaps you'll find the grace to file an > re> appropriate RFE? > > for what? The main problem I saw was with the wiki not warning people > away from archiving 'zfs send' emphatically enough, for example by > comparing its archival characteristics to tar (or checksummed cpio) > files and explaining that 'zfs send's output needs to be ephemeral. >
The reason is that zfs send/recv has very good application, even in the backup space. There are, in fact, many people using it. > This is RFE-worthy: > > >> * unresolved bugs. ``poisonous streams'' causing kernel panics > >> when you receive them, > >> http://www.opensolaris.org/jive/thread.jspa?threadID=81613&tstart=0 > Absolutely not an RFE! This is a bug! http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6783818 > but I'm not having the problem, so I won't file it when I can't > provide information. > > >> * stream format is not guaranteed to be forward compatible > > re> Backward compatibility is achieved. > > I've read complaints where the zfs filesystem version has to match. > People _have_ reported compatibility problems. Maybe it is true that > a newer system can always receive an older stream, but not vice-versa. > I'd not wish for more, and that removes this (but not other) > objections to archiving 'zfs send'. > That would be the definition of backwards compatibility. > not entirely though---When you archive it you care about whether > you'll be able to read it years from now. Suppose there IS some > problem receiving an old stream on a new system. Even if there's not > supposed to be, and even if there isn't right now, a bug may appear > later. I think it's less likely to get fixed than a bug importing an > old zpool. so, archive the zpool, not 'zfs send' output. > ZFS send is not an archival solution. You should use an archival method which is appropriate for your business requirements. Note: "method" above, not product or command. > re> An enterprising community member could easily put together a > re> utility to do a verification. All of the necessary code is > re> readily available. > > fine, but (a) what CAN be written doesn't change the fact that the > tool DOES NOT EXIST NOW, and the possibility of writing one isn't > enough to make archiving 'zfs send' streams a better idea which is > what I'm discussing, and (b) it's my opinion a thorough tool is not > possible, because as I said, a bunch of kernel code is implicated in > the zfs recv which is full of assertions itself. 'zfs recv' is > actually panicing boxes. so I'd not have faith in some userspace > tool's claim that a stream is good, since it's necessarily using > different code than the actual extraction. 'tar t', 'cpio -it', and I > think 'zpool scrub' don't use separate code paths for verification. > > >> * supposed to be endian-independent, but isn't. > >> > > re> CR 6764193 was fixed in b105 > re> http://bugs.opensolaris.org/view_bug.do?bug_id=6764193 Is > re> there another? > > no, no other, that is what I remember reading. 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. > Perhaps your memory needs to be using checksum=sha256 :-) I do not recall such a conversation or bug. > re> I suggest you consider an Enterprise Backup Solution. > > I prefer Free Software, especially for archival. But I will consider > the advice I gave: backup to another zpool, or to a tar/cpio file. > OK, one of the recommended solutions is Amanda, which is FOSS. The ZFS Best Practices Guide refers to this in the following bullet: Open source backup solutions are available. Joe Little blogs about how he backs up ZFS file systems <http://jmlittle.blogspot.com/2008/08/amanda-simple-zfs-backup-or-s3.html> to Amazon's S3 <http://aws.amazon.com/s3/> using Amanda. <http://www.zmanda.com> Integration of ZFS snapshots with MySQL and Amanda Enterprise 2.6 Software <http://www.sun.com/bigadmin/features/articles/zmanda_sfx4540.pdf> can also take advantage of ZFS snapshot capabilities. > I do not have a problem with the way 'zfs send' works. For > replication-like incremental backups, rolling back the entire recv for > one flipped bit is quite defendable. the lazy panics aren't, but the > architectural decision to trash a whole stream and all its descendent > incrementals for one flipped bit DOES make sense to me. but 'zfs > send' shouldn't be archived! That is what I'm saying, not > ``zfs send | zfs recv sucks'', just that it shouldn't be archived. I tend to agree, which is why it is called send/receive instead of backup/restore or archive -- historians will note that it was originally called backup, and changed accordingly. -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
