From owner-freebsd-fs@FreeBSD.ORG Sat Nov 12 15:12:58 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50977106564A for ; Sat, 12 Nov 2011 15:12:58 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id D2A798FC16 for ; Sat, 12 Nov 2011 15:12:57 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RPFGK-0003a5-34 for freebsd-fs@freebsd.org; Sat, 12 Nov 2011 16:12:56 +0100 Received: from dyn1240-121.vpn.ic.ac.uk ([129.31.240.121]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 12 Nov 2011 16:12:56 +0100 Received: from jtotz by dyn1240-121.vpn.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 12 Nov 2011 16:12:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Sat, 12 Nov 2011 15:12:43 +0000 Lines: 40 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dyn1240-121.vpn.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: Subject: Re: backing up zfs dataset X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 15:12:58 -0000 On 11/11/2011 20:40, Xin LI wrote: > On Fri, Nov 11, 2011 at 8:36 AM, Johannes Totz wrote: >> Hi, >> >> To back up a zfs dataset there are a few possibilities: >> 1) rsync file data to another machine >> 2) zfs-send to another machine, into a zfs dataset >> 3) zfs-send to another machine, dumping the stream to a file >> >> The first one works alright but you loose admin info, properties set on the >> dataset, etc >> The second is prefered but requires another machine which runs zfs. >> The third is bad. >> >> So far I have been doing (3), for daily short-term backups, works, tested, >> everything is peachy. However, I dont like it anymore for obvious reasons. >> Ideally, I would like to go with (2). But I dont have another zfs-capable >> machine, or the machine that I would like to backup onto will not ever run >> zfs. >> >> So I came up with another crazy idea, assuming the remote machine exports a >> block device (somehow): >> 4) zpool-attach the remote block dev as a mirror, let it resilver, offline >> it during the day, at night online it, resilver, and so on >> 5) create a pool on the block dev locally on the to-be-backed-up-machine and >> periodically zfs-send stuff over >> >> I would go for (4), it seems to be the mostly automatic. >> Any thoughts on this? >> Should I expect things to go titsup if there's network issues? > > I think this is not a good idea. Could you please try if zstreamdump > would fulfill your need? How do you mean? I didn't have a chance to test it yet but from looking at examples online, it dumps the stream-headers. Should I be trying this in combination with rsync to preserve properties? I could just pipe zfs get all to a file. However, restore should be as automatic as possible. This is where (4) would be quite nice: I could just dd the remote block dev into a new HDD.