zfs-autobackup prints the zfs commands it intends to run

Selection is done with a ZFS property, not a config file

The design decision that shapes everything else is how zfs-autobackup decides what to back up. It uses a custom ZFS property, which the documentation says makes it easy to add or remove specific datasets, or to back up a whole pool.

That is a different approach from a configuration file. There is no separate inventory to keep in sync with the storage, because the storage itself carries the answer. A dataset that should be backed up is marked as such on the dataset, and adding a filesystem to the backup set is a property change rather than an edit to a script.

Everything else is specified on the command line. The stated workflow is to set up and test the zfs-autobackup command and fix whatever problems come up, and then copy and paste the finished command into a cron job or script.

The project lists no configuration files or properties as a feature, describing it as no annoying config files or properties. For a tool that runs unattended, that is a genuine simplification, and for a reviewer it is also a real trade-off, since the command line becomes the only record of the intended policy.

The test mode runs the plan without changing anything

The feature the documentation singles out as missing from other tools is a reliable `--test` option. It lets you see what zfs-autobackup will do and tune your parameters, and it does everything except make changes to your system.

That is the core of why this tool is worth a look for a backup script. A backup job is hard to trust precisely because it is invisible until it fails, and a tool that can show you the full plan in advance converts an opaque scheduled task into something you can inspect on a laptop.

The companion to that is `--debug`. Since the tool works by invoking zfs commands, the debug output shows what it is actually doing. The documentation makes a point of this that is worth repeating: you can copy the command that fails and play around with it on the command line. That debugging loop is described as something other tools make difficult.

So there are two levels of inspection. `--debug` shows the real commands in flight, and `--test` shows the plan without executing the destructive parts. Combined, they mean a first run does not need to be trusted blindly.

Four transfer geometries, including a zero trust one

The tool describes itself as usable as a backup tool, a replication tool or a snapshot tool, and the backup modes are listed as four distinct arrangements.

The first backs up local data on the same server. The second is a push mode that sends local data to a backup server over SSH. The third is a pull mode that fetches remote data from a server over SSH and backs it up locally. The fourth is called pull+push and is described as zero trust between source and target.

That last label is the interesting one. In a push, the source machine holds the credentials to reach the target, so a compromised source can write to the backup. In a pull, the target holds the credentials. Combining them means neither side holds credentials that let it write to the other, at the cost of more coordination between the two machines.

The tool also supports complex backup geometries, and multiple backups from and to the same datasets are explicitly said to be no problem, which matters when you keep short-term and long-term retention on the same pool.

On scheduling, the answer is deliberately dull: a simple cron job, or running it directly from the command line. There are no complex daemons or services, and no additional software or networking needed, which is also why only one side of a pair needs the tool installed.

Snapshots, encryption and resuming are handled at the ZFS level

Several of the guarantees come from using ZFS primitives rather than from the tool inventing its own.

Snapshots are consistent because they are taken all at once, atomically, rather than one filesystem at a time. Older snapshots are thinned progressively. Important snapshots can be protected with zfs-holds so they cannot be deleted accidentally.

Encryption is supported in a way that goes beyond copying bytes. The tool can decrypt or encrypt datasets during transfer, and can even re-encrypt them, which is the operation you need when you move a dataset between pools with different key systems.

Failed transfers resume automatically, and the tool is described as resilient to errors. There is also a way to manually finish a failed backup to see what went wrong, which turns an interrupted run into something you can inspect rather than restart.

Two smaller behaviours are worth naming. Datasets that no longer exist on the source are handled gracefully, so a deleted filesystem does not abort the run. And the documentation claims migration from other zfs backup systems is easy, which matters if you are replacing an existing tool rather than starting from nothing.

Compression on send is supported using pigz, zstd and similar tools, and there is IO buffering to speed up transfer and bandwidth rate limiting to keep a backup from saturating a link.

The package installs with pip and ships three commands

Installation is described as easy: just install zfs-autobackup via pip, and it only needs to be installed on one side. The tool is written in Python and uses zfs commands, so there are no special third-party dependencies and no compiled libraries needed.

The packaging file confirms the shape of the tool. It defines three console scripts:

    'console_scripts':
            [
                'zfs-autobackup = zfs_autobackup.ZfsAutobackup:cli',
                'zfs-autoverify = zfs_autobackup.ZfsAutoverify:cli',
                'zfs-check = zfs_autobackup.ZfsCheck:cli',
            ]

So the main command is zfs-autobackup, and there are two companions: zfs-autoverify and zfs-check. The separate verify and check commands are consistent with the project's emphasis on letting you confirm the state of your backups rather than trusting that the job ran.

The declared runtime dependencies are minimal:

colorama
argparse

The colour library is there for readable terminal output, which matters for a tool whose selling point is that you read what it does. The development requirements add coverage, python-coveralls, unittest2 and mock, and the repository carries a Tests badge and a Coverage Status badge, along with a CodeQL workflow badge.

The metadata declares Python 3 only, an operating system independent classifier, and a GPL-3.0 licence.

The last push was on 2026-10-07, and the release tags around it are v4.0-rc2, v4.0-rc1 and v4.0-beta4, so the v4 line is still in release candidate form rather than shipped as a final version.

Where zfs-autobackup sits against the ZFS native tooling

The honest comparison is with what ZFS itself gives you, since zfs send and zfs receive can already move a filesystem between pools.

The native path is a handful of commands that you compose yourself. It is precise, scriptable, and it does exactly what you tell it. What it does not give you is selection across a pool, retention by progressive thinning, holds, resumable transfers, compression, rate limiting, and a plan you can inspect before running. Those are all things a backup tool adds on top of zfs send.

zfs-autobackup is also explicit about fitting into an existing setup rather than replacing it. The documentation says it plays nicely with existing replication systems, giving Proxmox HA as an example. That is the case for a script-level tool that shells out to zfs rather than a service with its own state.

Two limits are worth stating. The Python floor declared in the packaging is 3.2, which is conservative for a 2026 tool, and the recent release tags are release candidates rather than a final version, so the v4 line is still settling. The documentation points to a wiki with a getting started page and a full manual, and the sponsor list names JetBrains, rsync.net and DatuX.

Editorial conclusion

Adopt zfs-autobackup if you run ZFS and want a backup that you can rehearse before it runs, because the test mode and the printed commands are what make the tool safe to put on a cron schedule you did not write yourself. Skip it if you need a supported product with a support contract, or if you need a configuration-as-code approach, since the selection of datasets is done through a ZFS property rather than a config file. Verify first that the version you install is a stable release rather than a release candidate, since the recent tags are v4.0-rc2, v4.0-rc1 and v4.0-beta4, and check the wiki manual before you script it.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. psy0rz/zfs_autobackup on GitHub
4. README
5. Releases