On Tue, Jul 25, 2006 at 07:24:51PM -0500, Mike Gerdts wrote:
> On 7/25/06, Brad Plecs <[EMAIL PROTECTED]> wrote:
> >What I'd really like to see is ... the ability for the snapshot space
> >to *not* impact the filesystem space).
>
> The idea is that you have two storage pools - one for live data, one
> for backup data. Your live data is *probably* on faster disks than
> your backup data. The live data and backup data may or may not be on
> the same server. Whenever you need to perform backups you do
> something along the lines of:
>
> yesterday=$1
> today=$2
> for user in $allusers ; do
> zfs snapshot users/[EMAIL PROTECTED]
> zfs snapshot backup/$user/[EMAIL PROTECTED]
> zfs clone backup/$user/[EMAIL PROTECTED] backup/$user/$today
> rsync -axuv /users/$user/.zfs/snapshot/$today /backup/$user/$today
> zfs destroy users/[EMAIL PROTECTED]
> zfs destroy backup/$user/$lastweek
> done
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.
--matt
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
