Once again, I find I have to correct myself:
If you go to a future version of zfs, simply replace all your "full" filesystem streams with new ones, and then of course start new incrementals. Any reasonable backup procedure probably involves starting new full backups at regular intervals anyway, and more frequently than you update your filesystem ...
Of course many (most?) backup schemes will want archival backups, where new full backups do not REPLACE older full backups. So if you have older full backups, and the stream format changes, you'd need an older system to restore to. If you have a lot of data or a lot of archives, this could range from a nuisance to infeasible. There doesn't seem to be much reason to save the stream as opposed to saving a pax/tar/xxx archive anyway. With a replication type stream (zfs send -R), sure you get the filesystem properties but those are easily stashed away separately or even as a text file within the backed up filesystem itself. And at least if you use the Solaris tar you get all the ACLs, etc. I do wonder if backing up a mirror/raidz filesystem to a non-replicated disk, to be taken offsite, is a good practice. If we agree that the lack of a checksum of the zfs stream itself is the major problem, than it would seem that the lack of a parity or mirror disk in a backup filesystem is also problematic. I guess ditto blocks solve that problem? -frank _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
