From owner-freebsd-stable@FreeBSD.ORG Mon Mar 4 17:23:51 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 627262BD for ; Mon, 4 Mar 2013 17:23:51 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) by mx1.freebsd.org (Postfix) with ESMTP id D9DB395A for ; Mon, 4 Mar 2013 17:23:50 +0000 (UTC) Received: by mail-bk0-f49.google.com with SMTP id w11so2551862bku.36 for ; Mon, 04 Mar 2013 09:23:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sk5W3+3nvRe71nugnSyyifOd4kSdYPZ/Ub+d7GJViBA=; b=zMA0KF4uJlGEZjiP7tV8LcXC33/jrrBOg02BBliQiw9MGyaR1HKMeg/af6yXr5+VxF M1c8Hbjc0V1Ed/jZNhyi7osurfsq2BQ/VqUdiKcDIFmA4pGUGTUGw2XZRYRRC4tI+dHJ jKgskDuOSCAsGAnl8ibq9LXYz9uyrQh6Ikn8feikcCbJzmNSI8/1MiwgCUpMmpRU3p2d jhTtm+We+C09TJsOer5aPWxgkOjmzu+pmfYY0hfo1q+JDHoqSoj7VCoTKQ9mchB1GMdT QP8MJCregp3133efBQXksF8gi+eM0MizHhOeAErdb16PrFrMHCD+XgYDvUNxfG0by6bQ u+Fg== X-Received: by 10.204.141.17 with SMTP id k17mr7773232bku.67.1362417824038; Mon, 04 Mar 2013 09:23:44 -0800 (PST) Received: from [192.168.1.128] ([91.196.229.122]) by mx.google.com with ESMTPS id x18sm6123629bkw.4.2013.03.04.09.23.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Mar 2013 09:23:43 -0800 (PST) Message-ID: <5134D89E.3050004@gmail.com> Date: Mon, 04 Mar 2013 19:23:42 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16 MIME-Version: 1.0 To: David Magda Subject: Re: Musings on ZFS Backup strategies References: <5130BA35.5060809@denninger.net> <5130EB8A.7060706@gmail.com> <2B318078-F863-4415-8DAE-94EE4431BF4C@ee.ryerson.ca> <5134C6C2.9020009@gmail.com> <1e4c24a68e76a279eaf4dc4f7c0156d3.squirrel@webmail.ee.ryerson.ca> In-Reply-To: <1e4c24a68e76a279eaf4dc4f7c0156d3.squirrel@webmail.ee.ryerson.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 17:23:51 -0000 04.03.2013 19:04, David Magda: > On Mon, March 4, 2013 11:07, Volodymyr Kostyrko wrote: >> 02.03.2013 03:12, David Magda: >>> There are quite a few scripts out there: >>> >>> http://www.freshports.org/search.php?query=zfs >> >> A lot of them require python or ruby, and none of them manages >> synchronizing snapshots over network. > > Yes, but I think it is worth considering the creation of snapshots, and > the transfer of snapshots, as two separate steps. By treating them > independently (perhaps in two different scripts), it helps prevent the > breakage in one from affecting the other. Exactly. My script is just an addition to zfSnap or any other tool that manages snapshots. Currently it does nothing more then comparing list of available snapshots and network transfer. > Snapshots are not backups (IMHO), but they are handy for users and > sysadmins for the simple situations of accidentally files. If your network > access / copying breaks or is slow for some reason, at least you have > simply copies locally. Similarly if you're having issues with the machine > that keeps your remove pool. Yes, I addressed such thing specifically adding availability to restart transfer from any point or just even don't care - once initialized the process is autonomous and in case of failure anything would be rolled back to last known good snapshot. I also added possibility to compress/limit traffic. > By keeping the snapshots going separately, once any problems with the > network or remote server are solved, you can use them to incrementally > sync up the remote pool. You can simply run the remote-sync scripts more > often to do the catch up. > > It's just an idea, and everyone has different needs. I often find it handy > to keep different steps in different scripts that are loosely coupled. I just tried to give another use for snapshots. Or least the way to simplify things in one specific situation. -- Sphinx of black quartz, judge my vow.