ZREP replication and failover
This is the home for "zrep", a ZFS based replication and failover solution. It can also serve as the conduit to create a simple backup hub.

Contents

Downloads

Download zrep version 1.0.1 , May, 2013

Alternatively, some older versions are still available: zrep version 0.8.4 , Oct 17th, 2012 zrep version 0.7 , June 29th, 2012

Note that the download is not an archive, but a single 1000+ line shellscript. Just chmod +x zrep, and you are ready to go!

The license for zrep is available here. The short summary is that you are free to use it as much as you like,as long as you dont sue me for anything that goes wrong :-)
If you are really bored, you may also read the CHANGELOG

What is zrep?

Zrep is an enterprise-grade, single-program solution for handling asynchronous, continuous replication of a zfs filesystem, to another filesystem. That filesystem can be on another machine, or on the same machine.

It also handles 'failover', as simply as "zrep failover datapool/yourfs". This will conveniently handle all the details of

It also has user-friendly status outputs. For example: 
# zrep status
scratch/datasrc                      synced as of Mon Mar 12 13:23 2012

Why use zrep over (z-other-thing)?

I originally looked around for a pre-existing program that safely handled replication and failover of a zfs filesystem, but could not find one. Existing programs all seem to be some form of glorified rsync. They are not engineered to be run continuously, or safely. They often require a considerable amount of knowlege for a sysadmin to configure them well.

In contrast, zrep is designed to be

  1. Safe (has locking and other sanity checks)
  2. Easy to use
  3. Handles "failover" of active filesystem.
  4. Can be run frequently
zrep can safely be run in a loop, thereby potentially generating snap-and-replicate operations as frequently as 1-3 times a minute, and keep going safely for many years.

Overview of use, aka Documentation

I have finally written a web friendly zrep documentation page

A super-trivialized version of how to use zrep, would be: 

	zrep init pool/fs desthost destpool/fs
	# (will create the destination fs!)
	# Initialize additional fs's if you wish. Then..
	while true; do zrep sync all; done
After the initial full sync, this will do incremental zfs sends, back to back, "forever". (or at least until you hit an error :)

For some amount of greater detail, please see the usage message, via "zrep -h"

The one "undocumented feature" you may care about, is that the property zrep:savecount controls the number of recent snapshots preserved. To change from the default (currently, 5), use 

zfs set zrep:savecount=NEWVAL your/fs/here

There is also a separate troubleshooting page

Caution

There is one thing to beware of: Don't try to use zrep on nested filesystems.
It's okay to use it on
/pool/fs/here
Just don't try to use it on BOTH of 
/pool/fs/here
/pool/fs/here/too

Faster initialization and throughput

If you are planning to do a lot of "initial syncs", and your data is very large, you may be interested in looking at these patches to ssh. They make it have larger sized TCP windows, and also allow you to disable encyption on the transfer, if that helps you:

http://www.psc.edu/networking/projects/hpn-ssh/

 Some speed results, from local-host testing:
  using regular scp to regular sshd, got about  20MB/sec 
  using regular scp to hpn-sshd, got about 30MB/sec
  using hpc-scp to hpn-sshd, got 150MB/sec

Or, alternatively, you might want to just use rsh, if you blindly trust the security of your network from sniffing, and you put some kind of firewall or tcp wrappers around the listening demons (You can do this by setting SSH=rsh in your environment). It should be noted, however, that a zfs send has speed limits of its own, so you may want to first time "zfs send your@snapshot >/dev/null", to see if your gains are going to be significant. Unless you're sending from an SSD, it is probably simplest to just stick with SSH.

Source Code

zrep is a shellscript, so in essence, if you download it, you already have "the source". However, since it is a large scale script, I actually 'compile' it from multiple files, in a manner similar to other programming languages.
If you are a shellscript writer, this may interest you. Feel free to browse around the source directory

Written by:Philip Brown
Bolthole Top Search Bolthole.com