From owner-freebsd-stable@FreeBSD.ORG Tue Nov 23 12:46:06 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F6BF106566B for ; Tue, 23 Nov 2010 12:46:06 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwmtas05p.mx.bigpond.com (nschwmtas05p.mx.bigpond.com [61.9.189.149]) by mx1.freebsd.org (Postfix) with ESMTP id BF4208FC08 for ; Tue, 23 Nov 2010 12:46:05 +0000 (UTC) Received: from nschwotgx01p.mx.bigpond.com ([124.188.161.100]) by nschwmtas05p.mx.bigpond.com with ESMTP id <20101123124604.MTOT11322.nschwmtas05p.mx.bigpond.com@nschwotgx01p.mx.bigpond.com>; Tue, 23 Nov 2010 12:46:04 +0000 Received: from johnny.reilly.home ([124.188.161.100]) by nschwotgx01p.mx.bigpond.com with ESMTP id <20101123124603.BJVI8424.nschwotgx01p.mx.bigpond.com@johnny.reilly.home>; Tue, 23 Nov 2010 12:46:03 +0000 Date: Tue, 23 Nov 2010 23:45:43 +1100 From: Andrew Reilly To: Jonathan Stewart Message-ID: <20101123124543.GA4751@johnny.reilly.home> References: <20101122113541.GA74719@johnny.reilly.home> <4CEA8BA6.7080009@kc8onw.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CEA8BA6.7080009@kc8onw.net> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150202.4CEBB78C.0010,ss=1,fgs=0 X-SIH-MSG-ID: qh8yFdf7TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rHNvZRv9GgxDxPJhuHNGUmaazgTY3Rs9mK Cc: stable@freebsd.org Subject: Re: ZFS backups: retrieving a few files? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 12:46:06 -0000 On Mon, Nov 22, 2010 at 10:26:30AM -0500, Jonathan Stewart wrote: > On 11/22/2010 6:35 AM, Andrew Reilly wrote: > >Dump/restore doesn't work for ZFS. I *think* that I'm running > >backups in the appropriate equivalent fashion: I take file > >system snapshots (both absolute == level 0) and relative > >(incremental), and zfs send those to files on the backup disk. > > This is actively discouraged, there is no recovery ability when > receiving zfs streams so 1 bad bit would invalidate your entire backup. > > The currently accepted practice is to create a ZFS file system on the > backup drive and just keep sending incremental snapshots to it. As long > as the backup drive and host system have a snapshot in common you can do > incremental transfers. This way you only have to keep the most recent > snapshot on the main system and can keep as many as you have space for > on the backup drive. You also have direct access to any backed up > version of every file. For those playing along at home, I'll issue a small warning, based on today's frolics: Say, for example, one had done a: zfs send -vR tank/home@0 | zfs receive -d /backup/snapshots in order to experiment with this strategy. One would then become alarmed when one discovered that the receive mechanism also invoked the mountpoint= parameter of the source filesystem, and the zfs propensity for just doing stuff, and boom: you have a read-only version of your home directory mounted *on top of* your actual home directory... Required a reboot to single user mode, to go in and reset the mountpoint setting for the newly created file system (by way of hitting the power switch, after using zfs unmount -f to royally screw things up, preventing subsequent network logins.) Left wondering how to manage that change as part of an automated backup schedule. I think that this backup strategy has a few sharp edges... No, I don't like tar, rsync and friends for backups: they don't deal well with hard links, special files or sparse files. Cheers, -- Andrew