From owner-freebsd-questions@FreeBSD.ORG Sun Jul 27 14:27:03 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FB9BC4E for ; Sun, 27 Jul 2014 14:27:03 +0000 (UTC) Received: from avasout08.plus.net (avasout08.plus.net [212.159.14.20]) by mx1.freebsd.org (Postfix) with ESMTP id 0592520AF for ; Sun, 27 Jul 2014 14:27:02 +0000 (UTC) Received: from curlew.milibyte.co.uk ([84.92.153.232]) by avasout08 with smtp id XSSy1o004516WCc01SSzV1; Sun, 27 Jul 2014 15:26:59 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=TaoYtHgh c=1 sm=1 tr=0 a=lfSX4pPLp9EkufIcToJk/A==:117 a=lfSX4pPLp9EkufIcToJk/A==:17 a=D7rCoLxHAAAA:8 a=0Bzu9jTXAAAA:8 a=_gelNhxkGRwA:10 a=q7qFsdcGiHYA:10 a=ZTb9aqGL9YkA:10 a=8nJEP1OIZ-IA:10 a=_tjXruWMIvYW2hfNCVcA:9 a=wPNLvfGTeEIA:10 Received: from curlew.lan ([192.168.1.13]) by curlew.milibyte.co.uk with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XBPPd-0000vZ-W8 for freebsd-questions@freebsd.org; Sun, 27 Jul 2014 15:26:58 +0100 From: Mike Clarke To: freebsd-questions@freebsd.org Date: Sun, 27 Jul 2014 15:26:57 +0100 Message-ID: <2500431.kfCSzT8dFo@curlew.lan> User-Agent: KMail/4.12.5 (FreeBSD/9.1-RELEASE-p17; KDE/4.12.5; amd64; ; ) In-Reply-To: <53D41D5C.1010003@cyberleo.net> References: <1947386.pOQVzt1YdP@curlew.lan> <53D41D5C.1010003@cyberleo.net> MIME-Version: 1.0 X-SA-Exim-Connect-IP: 192.168.1.13 X-SA-Exim-Mail-From: jmc-freebsd2@milibyte.co.uk X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on curlew.lan X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Subject: Re: Backing up zfs system to external disk Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="iso-8859-1" X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on curlew.milibyte.co.uk) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 14:27:03 -0000 On Saturday 26 July 2014 16:27:56 CyberLeo Kitsana wrote: > Set canmount=off or noauto on the backup datasets. Beware that this > property is not inherited, so you must explicitly set it on every > dataset for which you wish to avoid auto-mounting. I'd already thought of this but prefer not to do it. The backup script would need to search through all the datasets changing the canmount properties of all mountable filesystems. The backup pool would no longer be an exact copy of the working system and would need manual changes to be made before it could be used for recovery. I'm using multiple boot environments created with sysutils/beadm so there's already a lot of datasets with canmount=noauto. It wouldn't be a simple case of just resetting all "noauto"s back to "on". By keeping the backup pool as an exact clone of a system snapshot recovery will just be a case of using zfs send | zfs receive to copy everything from the backup pool to the system pool. In fact if the system disks were totally trashed I could even boot directly off the backup until replacement disks arrived. -- Mike Clarke