> From: Peter Jeremy [mailto:peter.jer...@alcatel-lucent.com] > Sent: Sunday, January 30, 2011 3:48 PM > > >2- When you want to restore, it's all or nothing. If a single bit is > >corrupt in the data stream, the whole stream is lost. > > > OTOH, it renders ZFS send useless for backup or archival purposes.
Not useless for backup purposes. ZFS send is ideal for backup, as long as you're doing the zfs receive on-the-fly. Naturally that cannot be done while writing to tape. Also not useless for archival purposes. If you do a full ZFS send to tape every week, then it means you never have any backup that depends on any other backup, and you might estimate 1% probability of any one week's archive being corrupt. If you need to restore a 3yr old backup, you might be able to accept a tolerance of +/- 1 week with a probability of success being 99.9999%. Point is: It's all a calculation of risk, and every admin will choose differently based on their localized constraints. Don't generalize and use absolute terms like "useless." Personally, regarding backup reliability, I am more comfortable using "zfs send" to tape instead of other tools like bacula, tar, star, cpio, etc... Because I don't have to tweak any parameters in order to know with certainty I've preserved all file and object characteristics and ACL's and so forth which might not be clearly or well supported by those other tools. To me, the fear of unknown backup tools is higher than the fear of media corruption. To me, inability to do selective restore is a more important factor. Selective restore is my reason for not streaming zfs send to tape. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
