Date: Sun, 3 Mar 2013 11:47:54 +0630 From: Phil Regnauld <regnauld@x0.dk> To: Karl Denninger <karl@denninger.net> Cc: freebsd-stable@freebsd.org Subject: Re: Musings on ZFS Backup strategies Message-ID: <20130303051754.GE21613@macbook.bluepipe.net> In-Reply-To: <5132D843.4000800@denninger.net> References: <5130BA35.5060809@denninger.net> <5130EB8A.7060706@gmail.com> <20130303042301.GA54356@anubis.morrow.me.uk> <5132D843.4000800@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 :) Cheers, Phil
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130303051754.GE21613>