Hi list, I'd recommend using zfs send /receive and use a secondary machine that keeps the received filesystems in a backup pool. This gives you the advantage of being able to scrub your backups.
I'd like to add another question: Is there a way to efficiently replicating a complete zfs-pool including all filesystems and snapshots? Since it is currently impossible to change the vdev-structure of a pool the "easiest workaround" would be: 1. create the new pool. 2. create all the filesystems on the new pool 3. send all snapshots from the old pool and receive them in the new pool. If there was a way to do this for a whole pool or at least a full filesystem including history, this could be done with relative ease borrowing some cheap disk space. Any ideas? ralf --- this mail is made from 100% recycled electrons Am 29.05.2008 um 17:40 schrieb [EMAIL PROTECTED]: > Re: [zfs-discuss] zfs equivalent of ufsdump and ufsrestore > To: Darren J Moffat <[EMAIL PROTECTED]> > Cc: zfs-discuss@opensolaris.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >>> >> >> I very strongly disagree. The closest ZFS equivalent to ufsdump is >> 'zfs >> send'. 'zfs send' like ufsdump has initmiate awareness of the the >> actual on disk layout and is an integrated part of the filesystem >> implementation. >> >> star is a userland archiver. >> > > The man page for zfs states the following for send: > > The format of the stream is evolving. No backwards compati- > bility is guaranteed. You may not be able to receive your > streams on future versions of ZFS. > > I think this should be taken into account when considering 'zfs send' > for backup purposes... > > - Thomas _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
