From owner-freebsd-stable@FreeBSD.ORG Tue Nov 23 18:51:57 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 894E5106564A for ; Tue, 23 Nov 2010 18:51:57 +0000 (UTC) (envelope-from mwaltz@pacific.edu) Received: from mx40.pacific.edu (mx40.pacific.edu [138.9.110.107]) by mx1.freebsd.org (Postfix) with ESMTP id 63A048FC16 for ; Tue, 23 Nov 2010 18:51:57 +0000 (UTC) Received: from mx40.pacific.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8D42698BC45; Tue, 23 Nov 2010 10:36:22 -0800 (PST) Received: from exfe2.STK.PACIFIC.EDU (exfe2.stk.pacific.edu [10.9.4.22]) by mx40.pacific.edu (Postfix) with ESMTP id 25B8F98BC3A; Tue, 23 Nov 2010 10:36:22 -0800 (PST) Received: from EXVS2.stk.pacific.edu ([10.9.4.2]) by exfe2.STK.PACIFIC.EDU with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Nov 2010 10:36:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Nov 2010 10:35:27 -0800 Message-ID: <2A40FCBD209C654588C3F74D5BFF2C7C07B5468A@EXVS2.stk.pacific.edu> In-Reply-To: <20101123124543.GA4751@johnny.reilly.home> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ZFS backups: retrieving a few files? Thread-Index: AcuLDKSJYHam4vuBQp2BAzxHujdZWwALePow References: <20101122113541.GA74719@johnny.reilly.home><4CEA8BA6.7080009@kc8onw.net> <20101123124543.GA4751@johnny.reilly.home> From: "Malcolm Waltz" To: "Andrew Reilly" X-OriginalArrivalTime: 23 Nov 2010 18:36:22.0172 (UTC) FILETIME=[5394D5C0:01CB8B3D] X-PMX-Version: 5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.11.23.182115 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' BODY_SIZE_3000_3999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CANPHARM_UNSUB_LINK 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_XOAT 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __URI_NO_WWW 0, __URI_NS ' 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 18:51:57 -0000 If you end up in the double-mounted situation mentioned below, use "mount -v" to find the fsid for each double-mounted filesystem and then umount them using the fsid. To avoid this, always use the "-R" option (temporary, alternate root mount point) with zpool if you are working with a root pool. This also applies if you boot off of a CD or DVD and want to examine or modify a root pool. FWIW, I have successfully tested a bare metal restore from ZFS "full" and "incremental" send/receive backups (from an NFS mount off of a DataDomain). So, risks aside, it does work. I believe gzipped tar files would also fail if a bit flipped. -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Andrew Reilly Sent: Tuesday, November 23, 2010 4:46 AM To: Jonathan Stewart Cc: stable@freebsd.org Subject: Re: ZFS backups: retrieving a few files? 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 =3D=3D level 0) and relative > >(incremental), and zfs send those to files on the backup disk. >=20 > This is actively discouraged, there is no recovery ability when=20 > receiving zfs streams so 1 bad bit would invalidate your entire backup. >=20 > The currently accepted practice is to create a ZFS file system on the=20 > backup drive and just keep sending incremental snapshots to it. As long=20 > as the backup drive and host system have a snapshot in common you can do=20 > 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=20 > 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=3D 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, --=20 Andrew _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"