On Tue, Jul 25, 2006 at 08:37:28PM -0500, Mike Gerdts wrote: > On 7/25/06, Matthew Ahrens <[EMAIL PROTECTED]> wrote: > >You can simplify and improve the performance of this considerably by > >using 'zfs send': > > > > for user in $allusers ; do > > zfs snapshot users/[EMAIL PROTECTED] > > zfs send -i $yesterday users/[EMAIL PROTECTED] | \ > > ssh $host zfs recv -d $backpath > > ssh $host zfs destroy $backpath/$user/$lastweek > > done > > > >You can send the backup to the same or different host, and the same or > >different pool, as your hardware needs dictate. 'zfs send' will be much > >faster than rsync because we can use ZFS metadata to determine which > >blocks were changed without traversing all files & directories. > > > > This is what I had originally intended to say, but it seems with this > approach the yesterday snapshot has to stick around in order to do > incrementals. The fact that snapshots counted against current quota > was part of the problem statement. My approach with rsync avoids this > but, as I said before, is an ugly hack because it doesn't use the > features of zfs.
Ah yes, I overlooked that. It's a pity though, since implementation-wise, we don't really *need* the old snapshot, we just need to be sure that when we do the incremental receive, we're starting where we left off. Though potentially more complicated to administer, it should be possible to ensure that even without keeping the old snapshot around. I've filed RFE 6452850 "want incremental zfs send without initial snapshot" to track this enhancement. --matt _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
