From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 15:36:44 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 2FBCAD6B for ; Fri, 1 Mar 2013 15:36:44 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.net (24-240-198-187.static.stls.mo.charter.com [24.240.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id 0639F3C4 for ; Fri, 1 Mar 2013 15:36:43 +0000 (UTC) Received: from www.dweimer.net (webmail.dweimer.local [192.168.5.1]) by webmail.dweimer.net (8.14.5/8.14.5) with ESMTP id r21FaawY000860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 1 Mar 2013 09:36:37 -0600 (CST) (envelope-from dweimer@dweimer.net) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 01 Mar 2013 09:36:36 -0600 From: dweimer To: freebsd-stable@freebsd.org Subject: Re: Musings on ZFS Backup strategies Organization: dweimer.net Mail-Reply-To: dweimer@dweimer.net In-Reply-To: <5130BA35.5060809@denninger.net> References: <5130BA35.5060809@denninger.net> Message-ID: X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/0.8.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dweimer@dweimer.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 15:36:44 -0000 On 03/01/2013 8:24 am, Karl Denninger wrote: > 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. > > 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.) > > Am I missing something here? > > (Yes, I know, I've been a ZFS resister.... ;-)) I briefly did something like this between two FreeNAS boxes, it seemed to work well, but my secondary Box wasn't quite up to par hardware. Combine that with the lack of necessary internet bandwidth with a second physical location in case of something really disastrous, like a tornado or fire destroying my house. I ended up just using an eSATA drive dock and Bacula, with a few external drives rotated regularly into my office at work, rather than upgrading the secondary box. If you have the secondary box that is adequate, and either offsite backups aren't a concern or you have a big enough pipe to a secondary location that houses the backup this should work. I would recommend testing your incremental snapshot rotation, I never did test a restore from anything but the most recent set of data when I was running my setup, I did however save a weeks worth of hourly snapshots on a couple of the more rapidly changing data sets. -- Thanks, Dean E. Weimer http://www.dweimer.net/