On Jan 30, 2011, at 12:47 PM, Peter Jeremy wrote: > On 2011-Jan-28 21:37:50 +0800, Edward Ned Harvey > <opensolarisisdeadlongliveopensola...@nedharvey.com> wrote: >> 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. >> >> Regarding point #2, I contend that zfs send is better than ufsdump. I would >> prefer to discover corruption in the backup, rather than blindly restoring >> it undetected. > > OTOH, it renders ZFS send useless for backup or archival purposes. > > With ufsdump, I can probably recover most of the data off a backup > even if it has some errors. Since I'm aware of that problem, I can > separately store a file of expected checksums etc to verify what I > restore. If I lose a file from one backup, I can hopefully retrieve > it from another backup.
ufsdump is the problem, not ufsrestore. If you ufsdump an active file system, there is no guarantee you can ufsrestore it. The only way to guarantee this is to keep the file system quiesced during the entire ufsdump. Needless to say, this renders ufsdump useless for backup when the file system also needs to accommodate writes. > > With ZFS send, a 1-bit error renders my multi-GB backup useless. I > can't get ZFS to restore the rest of the backup and tell me what is > missing - which might let me recover it in other ways. Yes, these issues are discussed in the ZFS Best Practices Guide. If you need an Enterprise Backup Solution, then use an Enterprise Backup Solution. -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
