From owner-freebsd-stable@FreeBSD.ORG Sun Mar 3 05:26:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 980C6400 for ; Sun, 3 Mar 2013 05:26:39 +0000 (UTC) (envelope-from regnauld@x0.dk) Received: from moof.catpipe.net (moof.catpipe.net [194.28.252.64]) by mx1.freebsd.org (Postfix) with ESMTP id 59F8B665 for ; Sun, 3 Mar 2013 05:26:38 +0000 (UTC) Received: from localhost (moof.catpipe.net [194.28.252.64]) by localhost.catpipe.net (Postfix) with ESMTP id 9501F4CE954; Sun, 3 Mar 2013 06:17:57 +0100 (CET) Received: from moof.catpipe.net ([194.28.252.64]) by localhost (moof.catpipe.net [194.28.252.64]) (amavisd-new, port 10024) with ESMTP id NAsVN+2u44u2; Sun, 3 Mar 2013 06:17:57 +0100 (CET) Received: from macbook.bluepipe.net (unknown [122.248.97.220]) (Authenticated sender: relayuser) by moof.catpipe.net (Postfix) with ESMTPA id AA2874CE952; Sun, 3 Mar 2013 06:17:56 +0100 (CET) Received: by macbook.bluepipe.net (Postfix, from userid 1001) id 8EFF1222F8C; Sun, 3 Mar 2013 11:47:54 +0630 (MMT) Date: Sun, 3 Mar 2013 11:47:54 +0630 From: Phil Regnauld To: Karl Denninger Subject: Re: Musings on ZFS Backup strategies Message-ID: <20130303051754.GE21613@macbook.bluepipe.net> References: <5130BA35.5060809@denninger.net> <5130EB8A.7060706@gmail.com> <20130303042301.GA54356@anubis.morrow.me.uk> <5132D843.4000800@denninger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5132D843.4000800@denninger.net> X-Operating-System: Darwin 12.2.1 x86_64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 05:26:39 -0000 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