Musings on ZFS Backup strategies
regnauld at x0.dk
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