ZFS backups: retrieving a few files?
mwaltz at PACIFIC.EDU
Tue Nov 23 18:51:57 UTC 2010
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
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.
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
> The currently accepted practice is to create a ZFS file system on the
> backup drive and just keep sending incremental snapshots to it. As
> as the backup drive and host system have a snapshot in common you can
> 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
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.
freebsd-stable at freebsd.org mailing list
To unsubscribe, send any mail to
"freebsd-stable-unsubscribe at freebsd.org"
More information about the freebsd-stable