From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 15:24:28 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 7A6CAE54 for ; Sat, 2 Mar 2013 15:24:28 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id E397516B for ; Sat, 2 Mar 2013 15:24:27 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UBoIT-0003gV-6R; Sat, 02 Mar 2013 16:24:25 +0100 Received: from h253044.upc-h.chello.nl ([62.194.253.44] helo=pinky) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UBoIT-00068a-5F; Sat, 02 Mar 2013 16:24:25 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Karl Denninger" , freebsd-stable@freebsd.org, "Volodymyr Kostyrko" Subject: Re: Musings on ZFS Backup strategies References: <5130BA35.5060809@denninger.net> <5130EB8A.7060706@gmail.com> Date: Sat, 02 Mar 2013 16:24:28 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <5130EB8A.7060706@gmail.com> User-Agent: Opera Mail/12.14 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 18b3e585b0ef946fc0f6ee9ab4fcc4ff 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: Sat, 02 Mar 2013 15:24:28 -0000 On Fri, 01 Mar 2013 18:55:22 +0100, Volodymyr Kostyrko wrote: > 01.03.2013 16:24, Karl Denninger: >> Dabbling with ZFS now, and giving some thought to how to handle backup >> strategies. >> >> ZFS' snapshot capabilities have forced me to re-think the way that I've >> handled this. Previously near-line (and offline) backup was focused on >> being able to handle both disasters (e.g. RAID adapter goes nuts and >> scribbles on the entire contents of the array), a double-disk (or worse) >> failure, or the obvious (e.g. fire, etc) along with the "aw crap, I just >> rm -rf'd something I'd rather not!" >> >> ZFS makes snapshots very cheap, which means you can resolve the "aw >> crap" situation without resorting to backups at all. This turns the >> backup situation into a disaster recovery one. >> >> And that in turn seems to say that the ideal strategy looks more like: >> >> Take a base snapshot immediately and zfs send it to offline storage. >> Take an incremental at some interval (appropriate for disaster recovery) >> and zfs send THAT to stable storage. >> >> If I then restore the base and snapshot, I get back to where I was when >> the latest snapshot was taken. I don't need to keep the incremental >> snapshot for longer than it takes to zfs send it, so I can do: >> >> zfs snapshot pool/some-filesystem@unique-label >> zfs send -i pool/some-filesystem@base pool/some-filesystem@unique-label >> zfs destroy pool/some-filesystem@unique-label >> >> and that seems to work (and restore) just fine. > > Yes, I'm working with backups the same way, I wrote a simple script that > synchronizes two filesystems between distant servers. I also use the > same script to synchronize bushy filesystems (with hundred thousands of Your filesystems grow a lot of hair? :-) > files) where rsync produces a too big load for synchronizing. > > https://github.com/kworr/zfSnap/commit/08d8b499dbc2527a652cddbc601c7ee8c0c23301 > > I left it where it was but I was also planning to write some purger for > snapshots that would automatically purge snapshots when pool gets low on > space. Never hit that yet. > >> Am I looking at this the right way here? Provided that the base backup >> and incremental are both readable, it appears that I have the disaster >> case covered, and the online snapshot increments and retention are >> easily adjusted and cover the "oops" situations without having to resort >> to the backups at all. >> >> This in turn means that keeping more than two incremental dumps offline >> has little or no value; the second merely being taken to insure that >> there is always at least one that has been written to completion without >> error to apply on top of the base. That in turn makes the backup >> storage requirement based only on entropy in the filesystem and not time >> (where the "tower of Hanoi" style dump hierarchy imposed both a time AND >> entropy cost on backup media.) > > Well, snapshots can pose a value in a longer timeframe depending on > data. Being able to restore some file accidentally deleted two month ago > already saved 2k$ for one of our customers.