> > From what I've read so far, zfs send is a block level api and thus > > cannot be > > used for real backups. As a result of being block level oriented, the > > Weirdo. The above "cannot be used for real backups" is obviously > subjective, is incorrect and widely discussed here, so I just say > "weirdo." > I'm tired of correcting this constantly.
I apologize if I was insulting, and it's clear that I was. Seriously, I apologize. I should have thought about that more before I sent it, and I should have been more considerate. To clarify, more accurately, from a technical standpoint, what I meant: There are circumstances, such as backup to removable disks, or time-critical incremental data streams, where the performance of incremental "zfs send" versus the performance of star, rsync, or any other file-based backup mechanism, "zfs send" is the clear winner ... There are circumstances where zfs send is enormously a winner. There are other circumstances, such as writing to tape, where star, or tar, or in other circumstances, where rsync or other tools may be the winner... And I don't claim to know all the circumstances where something else beats "zfs send." There probably are many circumstances where some other tool beats "zfs send" in some way. The only point which I wish to emphasize is that it's not fair to say unilaterally that one technique is always better than another technique. Each one has their own pros/cons. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
