Date: Wed, 23 Nov 2011 15:50:17 +0000 From: Johannes Totz <johannes@jo-t.de> To: freebsd-fs@freebsd.org Subject: Re: backing up zfs dataset Message-ID: <jaj4nt$e5n$1@dough.gmane.org> In-Reply-To: <89025E71-B020-406A-BA58-BAF6529974A1@irbisnet.com> References: <j9jiud$oj6$1@dough.gmane.org> <89025E71-B020-406A-BA58-BAF6529974A1@irbisnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/11/2011 15:21, Andriy Bakay wrote: > On 2011-11-11, at 11:36 , 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 >> seton 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? As Xin mentioned, (4) is not a good idea. Onlining a device starts a resilver from scratch. This is not incremental, i.e. not suited for a nightly backup thing. > > I am using the following schema: sparse file + GGATE + GELI + ZFS. > The destination (remote) machine export/share sparse file through > GGATE. The source/local machine attach GGATE block device, encrypted > with GELI and on top of it create "local" ZFS pool. You can skip GELI > and/or instead sparse file you can use any block device. In this > scenario destination/remote machine does not even know what inside > that sparse file and does not need to support ZFS. You could > periodically attach GGATE/GELI, import ZFS pool and > zfs-send/zfs-receive snapshot(s). This is quite similar to (5) above, and is what I'm going to do. Thanks to you and Xin for suggestions! > > NOTE: GELI will provide storage security, but I am not sure will it > be secure in terms of transmission. Basically you need to make sure > your GGATE layer go through secure/trusted (VPN, SSH tunnel, trusted > LAN) link. > > You could mirror to remote GGATE devices, but it could lead to some > problems (try to search it in mailing list). In this case I recommend > you to consider HAST.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?jaj4nt$e5n$1>