Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 12 Nov 2011 10:21:21 -0500
From:      Andriy Bakay <andriy@irbisnet.com>
To:        Johannes Totz <jtotz@imperial.ac.uk>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: backing up zfs dataset
Message-ID:  <89025E71-B020-406A-BA58-BAF6529974A1@irbisnet.com>
In-Reply-To: <j9jiud$oj6$1@dough.gmane.org>
References:  <j9jiud$oj6$1@dough.gmane.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2011-11-11, at 11:36 , Johannes Totz wrote:

> Hi,
>=20
> 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
>=20
> 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.
>=20
> 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.
>=20
> 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
>=20
> 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?
>=20
>=20
>=20
> Johannes
>=20
> _______________________________________________
> freebsd-fs@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"

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).

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?89025E71-B020-406A-BA58-BAF6529974A1>