ZFS backups: retrieving a few files?
Andrew Reilly
areilly at bigpond.net.au
Tue Nov 23 12:46:06 UTC 2010
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
More information about the freebsd-stable
mailing list