The following design aspects may convince you that
zrepl is superior to a hacked-together shell script solution.
Also check out the talks about zrepl at various conferences.
Testability & Performance¶
zrepl is written in Go, a real programming language with type safety, reasonable performance, testing infrastructure and an (opinionated) idea of software engineering.
- key parts & algorithms of zrepl are covered by unit tests (work in progress)
- zrepl is noticably faster than comparable shell scripts
While it is tempting to just issue a few
ssh remote 'zfs send ...' | zfs recv, this has a number of drawbacks:
- The snapshot streams need to be compatible.
- Communication is still unidirectional. Thus, you will most likely
- either not take advantage of advanced replication features such as compressed send & recv
- or issue additional
sshcommands in advance to figure out what features are supported on the other side.
- Advanced logic in shell scripts is ugly to read, poorly testable and a pain to maintain.
zrepl takes a different approach:
- Define an RPC protocol.
- Establish an encrypted, authenticated, bidirectional communication channel.
- Run daemons on both sides of the setup and let them talk to each other.
This has several obvious benefits:
- No blank root shell access is given to the other side.
- An authenticated peer requests filesystem lists, snapshot streams, etc.
- The server decides which filesystems it exposes to which peers.
- The transport mechanism is decoupled from the remaining logic, which allows us to painlessly offer multiple transport mechanisms.