Musings on ZFS Backup strategies

[Volodymyr Kostyrko]

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.