Musings on ZFS Backup strategies

Phil Regnauld regnauld at
Sun Mar 3 05:26:39 UTC 2013

Karl Denninger (karl) writes:
> I think I'm going to play with this and see what I think of it.  One
> thing that is very attractive to this design is to have the receiving
> side be a mirror, then to rotate to the vault copy run a scrub (to
> insure that both members are consistent at a checksum level), break the
> mirror and put one in the vault, replacing it with the drive coming FROM
> the vault, then do a zpool replace and allow it to resilver into the
> other drive.  You now have the two in consistent state again locally if
> the pool pukes and one in the vault in the event of a fire or other
> "entire facility is toast" event.

	That's one solution.

> The only risk that makes me uncomfortable doing this is that the pool is
> always active when the system is running.  With UFS backup disks it's
> not -- except when being actually written to they're unmounted, and this
> materially decreases the risk of an insane adapter scribbling the
> drives, since there is no I/O at all going to them unless mounted. 
> While the backup pool would be nominally idle it is probably
> more-exposed to a potential scribble than the UFS-mounted packs would be.

	Could "zpool export" in between syncs on the target, assuming that's not
	your root pool :)


More information about the freebsd-stable mailing list