ZFS backups: retrieving a few files?

[Malcolm Waltz]

If you end up in the double-mounted situation mentioned below, use
"mount -v" to find the fsid for each double-mounted filesystem and then
umount them using the fsid.

To avoid this, always use the "-R" option (temporary, alternate root
mount point) with zpool if you are working with a root pool.  This also
applies if you boot off of a CD or DVD and want to examine or modify a
root pool.

FWIW, I have successfully tested a bare metal restore from ZFS "full"
and "incremental" send/receive backups (from an NFS mount off of a
DataDomain).  So, risks aside, it does work.  I believe gzipped tar
files would also fail if a bit flipped.


-----Original Message-----
From: owner-freebsd-stable at freebsd.org
[mailto:owner-freebsd-stable at freebsd.org] On Behalf Of Andrew Reilly
Sent: Tuesday, November 23, 2010 4:46 AM
To: Jonathan Stewart
Cc: stable at freebsd.org
Subject: Re: ZFS backups: retrieving a few files?

On Mon, Nov 22, 2010 at 10:26:30AM -0500, Jonathan Stewart wrote:
> On 11/22/2010 6:35 AM, Andrew Reilly wrote:
> >Dump/restore doesn't work for ZFS.  I *think* that I'm running
> >backups in the appropriate equivalent fashion: I take file
> >system snapshots (both absolute == level 0) and relative
> >(incremental), and zfs send those to files on the backup disk.
> 
> This is actively discouraged, there is no recovery ability when 
> receiving zfs streams so 1 bad bit would invalidate your entire
backup.
> 
> The currently accepted practice is to create a ZFS file system on the 
> backup drive and just keep sending incremental snapshots to it.  As
long 
> as the backup drive and host system have a snapshot in common you can
do 
> incremental transfers.  This way you only have to keep the most recent

> snapshot on the main system and can keep as many as you have space for

> on the backup drive.  You also have direct access to any backed up 
> version of every file.

For those playing along at home, I'll issue a small warning,
based on today's frolics:

Say, for example, one had done a:

zfs send -vR tank/home at 0 | zfs receive -d /backup/snapshots

in order to experiment with this strategy.

One would then become alarmed when one discovered that the
receive mechanism also invoked the mountpoint= parameter of the
source filesystem, and the zfs propensity for just doing stuff,
and boom: you have a read-only version of your home directory
mounted *on top of* your actual home directory...

Required a reboot to single user mode, to go in and reset the
mountpoint setting for the newly created file system (by way of
hitting the power switch, after using zfs unmount -f to royally
screw things up, preventing subsequent network logins.)  Left
wondering how to manage that change as part of an automated
backup schedule.

I think that this backup strategy has a few sharp edges...

No, I don't like tar, rsync and friends for backups: they don't
deal well with hard links, special files or sparse files.

Cheers,

-- 
Andrew
_______________________________________________
freebsd-stable at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to
"freebsd-stable-unsubscribe at freebsd.org"