Date: Fri, 01 Mar 2013 16:06:05 +0100 From: "Ronald Klop" <ronald-freebsd8@klop.yi.org> To: freebsd-stable@freebsd.org, "Karl Denninger" <karl@denninger.net> Subject: Re: Musings on ZFS Backup strategies Message-ID: <op.ws9v8fvs8527sy@ronaldradial.versatec.local> In-Reply-To: <5130BA35.5060809@denninger.net> References: <5130BA35.5060809@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 01 Mar 2013 15:24:53 +0100, Karl Denninger <karl@denninger.net> 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 do the same. I only use zfs send -I (capital i) so I have all the snapshots on the backup also. That way the data survives an oops (rm -r) and a fire at the same time. :-) Ronald.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.ws9v8fvs8527sy>