zrep simplifies ZFS replication for the use-case we’re demonstrating. However, we’ll also discuss many concepts and aspects of ZFS that are not specific to zrep. zrep itself is not available from ports, but it only consists of a single shell script. The stable version of zrep needs ksh as its operating shell, though the newer version from GitHub can also use bash. The script needs to be installed in a directory that is included in $PATH on both systems. On FreeBSD, you may want to change the first line to point to the correct location of ksh or bash in /usr/local/bin.

Initially, it may also be useful to setup keys to allow password-less ssh logins for root between the two systems. This was covered in the article Introduction to ZFS Replication. You may later prefer an alternative to ssh and perhaps to use zfs allow to avoid using root but a familiar tool like ssh is convenient. //

One possible scenario occurs where we’ve used a forced takeover from the standby system to deal with the production system being fully down. When the broken system does come up again, the ZFS properties will still identify it as the master and the dataset will be writable. This can be manually rectified on the formerly broken system by putting the properties into the correct state for a standby system as follows:

zfs inherit zrep:master tank/zrep-test
zfs set readonly=on tank/zrep-test

Any attempts to perform syncs with zrep will potentially still fail because changes have occurred to the dataset on both sides. While it is generally able to cope automatically, it is useful to know how to rollback the datasets on the standby system to the last successfully sent snapshot so that zrep can work again. This is a solution for nearly all failure scenarios.

For a rollback, the first step is to identify the last snapshot that was sent successfully.