From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 20:34:40 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 8054B49C for ; Fri, 1 Mar 2013 20:34:40 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4A4661677 for ; Fri, 1 Mar 2013 20:34:40 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r21KYd9X005747; Fri, 1 Mar 2013 15:34:39 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.10]); Fri, 01 Mar 2013 15:34:39 -0500 (EST) Date: Fri, 1 Mar 2013 15:34:39 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Ben Morrow Subject: Re: Musings on ZFS Backup strategies In-Reply-To: <20130301185912.GA27546@anubis.morrow.me.uk> Message-ID: References: <20130301165040.GA26251@anubis.morrow.me.uk> <20130301185912.GA27546@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen 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 20:34:40 -0000 On Fri, 1 Mar 2013, Ben Morrow wrote: > Quoth Daniel Eischen : >> >> Yes, we still use a couple of DLT autoloaders and have nightly >> incrementals and weekly fulls. This is the problem I have with >> converting to ZFS. Our typical recovery is when a user says >> they need a directory or set of files from a week or two ago. >> Using dump from tape, I can easily extract *just* the necessary >> files. I don't need a second system to restore to, so that >> I can then extract the file. > > As Karl said originally, you can do that with snapshots without having > to go to your backups at all. With the right arrangements (symlinks to > the .zfs/snapshot/* directories, or just setting the snapdir property to > 'visible') you can make it so users can do this sort of restore > themselves without having to go through you. It wasn't clear that snapshots were traversable as a normal directory structure. I was thinking it was just a blob that you had to roll back to in order to get anything out of it. Under our current scheme, we would remove snapshots after the next (weekly) full zfs send (nee dump), so it wouldn't help unless we kept snapshots around a lot longer. Am I correct in assuming that one could: # zfs send -R snapshot | dd obs=10240 of=/dev/rst0 to archive it to tape instead of another [system:]drive? -- DE