From owner-freebsd-fs@FreeBSD.ORG Sat Nov 12 15:35:28 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 DEDAA106564A for ; Sat, 12 Nov 2011 15:35:27 +0000 (UTC) (envelope-from andriy@irbisnet.com) Received: from nm14-vm0.access.bullet.mail.mud.yahoo.com (nm14-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.15]) by mx1.freebsd.org (Postfix) with SMTP id A53448FC08 for ; Sat, 12 Nov 2011 15:35:27 +0000 (UTC) Received: from [66.94.237.198] by nm14.access.bullet.mail.mud.yahoo.com with NNFMP; 12 Nov 2011 15:21:23 -0000 Received: from [98.139.221.68] by tm9.access.bullet.mail.mud.yahoo.com with NNFMP; 12 Nov 2011 15:21:23 -0000 Received: from [127.0.0.1] by smtp105.rog.mail.bf1.yahoo.com with NNFMP; 12 Nov 2011 15:21:22 -0000 X-Yahoo-Newman-Id: 968268.57319.bm@smtp105.rog.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: HX1InGYVM1kFwaAhJoQ3HKtN0yi6VF68tgke_Xc.R5D5QHJ v8v.Z4AofkLAouijTbepVbEJgRE_iyTau4VCfpORJG.nyuIT03T18MM8k2JE QAMtWs6VwCzMDWmlywBUF.wMCRgkp_SUL2e0adX.N2B2Y7.lBwuIn21pEx5M Z_JmENov_DT5pnwqCWrL52SJS6NBPtUoTetrd3YVzqSzAL0O03bcby6auzhs OZnUTGze7s8qIOZLu.WCY.6ZKv5qnYun4P8I3r6Lvr8MrMqdVgDcGhi1skda iqLO3tjPcUxV6WCIfsAtIKLMAtpBzShbRNA8p_qJZl2V.7UR7MqaWIQUZFF1 6iCJTfitbAj8IXCLuifFVr1lpUFHOVZOYHr0LSDAP4VYA2CacWRkOIzzGnzz QZlJbYf_A_p66VDB0MKSoVQ-- X-Yahoo-SMTP: dz9sigaswBA5kWoYWVTZrGHmIs2vaKgG1w-- Received: from smtp.irbisnet.com (andriy@174.113.73.248 with login) by smtp105.rog.mail.bf1.yahoo.com with SMTP; 12 Nov 2011 07:21:22 -0800 PST Received: from pollux.irbisnet.lan (pollux.local [192.168.0.6]) by smtp.irbisnet.com (Postfix) with ESMTPSA id 06030296D8; Sat, 12 Nov 2011 10:21:22 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Andriy Bakay In-Reply-To: Date: Sat, 12 Nov 2011 10:21:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <89025E71-B020-406A-BA58-BAF6529974A1@irbisnet.com> References: To: Johannes Totz X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-fs@freebsd.org 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:35:28 -0000 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.