rdiff-backup: reverse incremental backup on top of librsync

The newest copy is always a full backup

rdiff-backup is a reverse differential backup tool that can be used locally and remotely. The description is short, and the mechanism is the interesting part.

Because rdiff-backup only stores the differences from the previous backup to the next one, a so called reverse incremental backup, the latest backup is always a full backup. That gives the combination the README describes: the space advantages of incremental backups while keeping the speed advantages of full backups, at least for recent ones.

That is a different arrangement from the usual incremental backup, where the newest copy is the smallest and restoring means walking a chain of deltas back to a base. Here the chain runs the other way. Each run produces a complete, current copy of the tree, and the older states are recovered from the differences stored alongside.

The practical consequence is that the most common operation, restoring yesterday, is fast, because it is a read of a full tree rather than an accumulation of patches. The cost moves to the rarer operation, restoring a point in time from months ago, which has to be reconstructed.

The tool uses the same efficient protocol as rsync to transfer and store data, which is what makes the on-disk format compact and the transfer efficient. The Python dependency list makes the implementation clear: `librsync` or `librsync2`, version 2.0.0 or higher, is the core, and the setup.py builds against it as a native extension with `libname = ["rsync"]` and supports pointing at a custom build through the `LIBRSYNC_DIR`, `LFLAGS` and `LIBS` environment variables.

Installing on Linux, and the librsync prerequisite

The simplest installation is through the distribution package, and the README gives two examples:

sudo apt install rdiff-backup  # Debian, Ubuntu & Co
sudo dnf install rdiff-backup  # Fedora

The package is available in many distributions, so the standard system installation method is usually the right first move. The RHEL family needs EPEL, and the README gives the three generation-specific recipes, since the repository name changes between them: `dnf config-manager --set-enabled crb` and `dnf install epel-release` on RHEL 9 and 10, `dnf --enablerepo=PowerTools install rdiff-backup` on RHEL 8, and the older `yum install epel-release` followed by `yum install rdiff-backup` on RHEL 7. The RHEL 7 recipe also installs `py3libacl` and `pyxattr`, with a note that the last line is optional and only needed for ACL and extended attribute support.

The PyPI route is for anything UN*X-oid and needs more setup. The requirements are Python 3.10 or higher, pip, librsync 2.0.0 or higher, and optionally libacl and SSH. The dependency install differs by distribution, for example `sudo apt install python3-pip python3-setuptools python3-pylibacl python3-pyxattr` plus `sudo apt install build-essentials librsync-dev` on Debian and derivatives, and a note that the last line is probably necessary if your platform is not i386 or amd64, such as ARM or MIPS.

Then the install itself is one of two commands:

pip3 install rdiff-backup        # without optional dependencies
pip3 install rdiff-backup[meta]  # with support for metadata, ACLs and EAs

The `meta` extra pulls in `pylibacl` on POSIX, `pyxattr` on Linux and `psutil`.

The README carries an explicit caution about installing with pip as root, and about not mixing system and pip libraries, since a dependency already packaged for your distribution should not also be installed through pip. A virtual environment is offered as the safer option, with the acknowledged price of added complexity.

Windows support and the 2.1.1 Python bump

rdiff-backup works locally and remotely on Linux and Windows, and even cross-platform between the two. Users have reported using it successfully on FreeBSD and MacOS X, which the project classifiers reflect with a generic POSIX entry and a comment explaining that it is because users reported FreeBSD to work.

On Windows there is one hard constraint, stated in a note: starting with rdiff-backup 2.1.1, which embedded Python 3.10, rdiff-backup cannot be used on Windows 7 or earlier. That is a consequence of the Python version rather than a decision about Windows support, and it is the kind of line worth reading before you plan an upgrade for an old machine.

For remote operations on Windows you need an SSH package installed, and the README suggests the one provided by Microsoft as the safest choice, with OpenSSH from mls-software.com as the alternative.

The prebuilt Windows route is a zip archive from the releases section. The asset is named `rdiff-backup-VERSION.win64exe.zip`, or the win32 variant, and you drop `rdiff-backup.exe` somewhere in your PATH. The README notes it should work as it comes with all dependencies included, which is the point of the PyInstaller step in the requirements file, since `pyinstaller` is listed under the building packages section with a Windows platform marker.

Chocolatey is named as another option for Windows installation.

The development container in the repository makes the same point in a different way. The Dockerfile is built from debian:sid and installs the full toolchain, including `librsync-dev`, `python3-pylibacl`, `python3-yaml`, `python3-pyxattr` and `libacl1-dev` with a comment that the acl header is required by test builds. It also creates a regular test user, since the tests require one, and it installs `rsync` because tox_slow uses it for comparative benchmarking.

ACLs, extended attributes and the meta extra

If the optional dependencies pylibacl and pyxattr are installed, rdiff-backup supports Access Control Lists and Extended Attributes, provided the file systems also support those features.

The second half of that condition is the one that bites. The Python bindings are only half of it, since a filesystem that cannot store the metadata will silently drop it, and a backup that appears to preserve permissions while quietly losing them is worse than one that documents the limitation. The README's phrasing, provided the file systems also support these features, is doing real work.

The extras group is named `meta`, and the pip command is `pip3 install rdiff-backup[meta]`. The dependencies are conditional on the platform, with `pylibacl` marked for POSIX and `pyxattr` for Linux, plus `psutil` unconditionally.

The distribution packaging route handles the same thing in the other direction, with `python3-pylibacl` and `python3-pyxattr` installed alongside the package on Debian, and the equivalent on RHEL. There is even a note about weakening the dependency install, since on RHEL you can add the option `--setopt=install_weak_deps=False` to the last line if you do not need ACL and extended attribute support. The underlying `libacl` and `xattr` packages can also be installed separately.

The requirements file is generated rather than hand written, and the file says so at the top: it is produced by concatenating the files in `requs/`. That is a deliberate choice, and the comment explains the reasoning about version pinning, which is that not pinning increases the chance of detecting non-working combinations of dependency versions.

Development, releases and where the project stands

The repository is set up for a long-lived open source project. The `src/` directory holds the package, `docs/` holds the AsciiDoc documentation including the migration guide referenced from the README, `debian/` holds the distribution packaging, `testing/` the test infrastructure, and `tools/` the helper scripts. There are six tox configuration files, split by purpose into root, dist, slow, smoke and win variants, which is how a project separates a fast feedback loop from the slow and platform-specific runs.

The build uses setuptools with setuptools-scm, so the version number is derived from the git tags rather than being written into a file. The entry point is `rdiff-backup = "rdiffbackup.run:main"`, and the platforms are declared as linux and win32.

The release history explains the tag names. There is a `weekly` release, which the releases list shows as Weekly Release 2026-10-10, alongside v2.2.6 tagged as the final minor release on 2023-09-08 and v2.5.0 and v2.5.1 as minor fix releases in May 2023. The pattern is that the 2.x line reached a final minor release and development continued on a weekly cadence afterwards, which is a sensible arrangement for a tool where the on-disk format has to stay stable for existing backups.

The last push was on 2026-10-14, and the repository is not archived. The licence is GPL-2.0-or-later, and the project carries an OpenSSF Best Practices badge along with separate Linux and Windows CI workflow badges, both of which is the norm for a tool that has to behave the same on two very different operating systems.

The community is a mailing list at lists.nongnu.org, and the project address in the metadata is [email protected], which is the same list.

Editorial conclusion

rdiff-backup fits a system administrator who wants a backup that restores the most recent state in one step without giving up the space saving of incrementals, and who can accept that a restore of an older point in time is slower. It does not fit a team wanting a modern deduplicating store or a snapshot-oriented design, and the librsync dependency is a real prerequisite on older systems. Before installing, add librsync 2.0.0 or higher and, if you need permissions preserved, the `meta` extra, then confirm your backup directory is on a filesystem that supports the metadata you rely on.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. rdiff-backup/rdiff-backup on GitHub
4. README
5. Releases