* zrepl is a great tool, but I think it has a different focus and angle and serves different needs.
* In a nutshell, bzfs can operate at much larger scale than zrepl, at much lower latency, in a more flexible and straightforward way.
* Here are just a few points off the top of my head that bzfs does and zrepl doesn't:
* manage periodic ZFS snapshot creation, replication, pruning, and monitoring, across a fleet of N source hosts and M destination hosts, using the same single shared fleet-wide jobconfig script. Each of the M destination hosts receives replicas from (the same set of) N src hosts.
* Monitor if snapshots are successfully taken on schedule, successfully replicated on schedule, and successfully pruned on schedule, across the entire fleet.
* More powerful include/exclude filters for selecting what datasets and snapshots and properties to replicate.
* Can be strict or told to be tolerant of runtime errors.
* Has parametrizable retry logic
* Can be used not just for backup, but also for low latency replication use cases
* Other aspects:
* bzfs is actively maintained whereas zrepl seems mostly dormant.
* The zrepl codebase is vastly more complex and larger than bzfs; IMO, the designs and abstractions it introduces are more complex than they need to be. For example, building a home grown daemon and secure transport layer is more a liability than upside for a tool like this. Complexity has a prize.
* bzfs is easier to change, test and maintain because Python is more readable to contemporary engineers than Go and because the codebase is so much smaller and more straightforward than zrepl.
* These are just some points. Maybe the most important point is that zrepl is more a monolithic end user app than a building block. I believe it's good to have an rsync'ish CLI for ZFS replication that keeps simple things simple, and makes complex things possible, and enables higher level infra and various UIs to be built on top of that. bzfs aims to be that.
Many people use zrepl, how does this compare?
* zrepl is a great tool, but I think it has a different focus and angle and serves different needs. * In a nutshell, bzfs can operate at much larger scale than zrepl, at much lower latency, in a more flexible and straightforward way. * Here are just a few points off the top of my head that bzfs does and zrepl doesn't:
* Other aspects: * bzfs is actively maintained whereas zrepl seems mostly dormant. * The zrepl codebase is vastly more complex and larger than bzfs; IMO, the designs and abstractions it introduces are more complex than they need to be. For example, building a home grown daemon and secure transport layer is more a liability than upside for a tool like this. Complexity has a prize. * bzfs is easier to change, test and maintain because Python is more readable to contemporary engineers than Go and because the codebase is so much smaller and more straightforward than zrepl.* These are just some points. Maybe the most important point is that zrepl is more a monolithic end user app than a building block. I believe it's good to have an rsync'ish CLI for ZFS replication that keeps simple things simple, and makes complex things possible, and enables higher level infra and various UIs to be built on top of that. bzfs aims to be that.
Sounds awesome. What happens if you cleanup the source by deleting oldest snapshots? Is it able to replicate this, too?
You can do that if you like, yes. You can set snapshot retention rules that are separate (or the same) for source and destination.