rsnapshot: hard-link snapshots on top of rsync

The problem rsnapshot solves: many restore points without many full copies

A plain rsync job gives you one current mirror. If a file is corrupted on Monday and you only notice on Thursday, the mirror has already overwritten the good copy. rsnapshot exists to keep a rotating series of snapshots instead, so you can reach back several intervals. It is aimed at people who administer Unix machines and already trust rsync: the README describes it as "a filesystem snapshot utility based on rsync" that makes periodic snapshots of local machines and remote machines over ssh. The design bet is that most files do not change between runs, so an unchanged file is stored once and every later snapshot points at the same inode through a hard link. That is what keeps the disk cost near the size of the data plus the deltas, rather than multiplying the dataset by the number of snapshots. The project is written entirely in Perl with no module dependencies and the README says it has been tested with Perl 5.12.0 upwards on a long list of UNIX systems, from Debian and RHEL through FreeBSD, OpenBSD, Solaris and Mac OS X. If your estate is Windows, the README lists no Windows target at all.

How the interval rotation actually works

The mechanism is rotation, not incremental backup. You define named intervals in the config, and the README is explicit that "it is only the lowest interval which actually does the rsync to back up the relevant source directories, the higher intervals just rotate snapshots around." So a beta run does not copy data; it promotes the newest alpha snapshot to become the newest beta snapshot, and the snapshot directories are renamed in sequence. The retain directive sets how many of each are kept: "retain\talpha\t\t6" means each alpha run makes a new snapshot, rotates the old ones, and keeps the most recent six, named alpha.0 through alpha.5. There is a consequence people miss. The README states that "a higher interval will rotate the oldest snapshot of the interval one step lower as its newest snapshot", so if daily keeps 30 and you also run weekly, the newest weekly snapshot is the oldest daily snapshot, already 30 days old at the moment it is promoted. Your weekly tier is not a fresh copy of today's data. There is also an ordering rule: backups run from the highest interval down to the lowest, and if cron does not invoke the lowest interval you must comment that interval out of the config so the next one down becomes the base. The sync_first option changes the picture again: with it enabled, only the sync pseudo-interval performs the rsync, and every real interval just rotates.

Installing rsnapshot and running a first dry run

The README points to INSTALL.md for installation and upgrade instructions, so the exact package or build command depends on how your distribution ships it. What the README does specify is the configuration path and the sanity checks. The default config file is /etc/rsnapshot.conf, and if it does not exist you copy /etc/rsnapshot.conf.default over it and edit from there. Copying the default config is the first step:

cp /etc/rsnapshot.conf.default /etc/rsnapshot.conf

Then check that the file parses and that the binaries it references are present:

rsnapshot configtest

A passing configtest means the settings are usable. Before trusting it with real data, the README gives a preview mode, where interval is alpha, beta, or whatever names you defined:

rsnapshot -t beta

That prints essentially what would happen on a real run, so you can confirm the source paths and the destination before anything is written. The final step is cron. The README's example runs alpha every four hours and beta once a night:

0 */4 * * *     /usr/local/bin/rsnapshot alpha
50 23 * * *     /usr/local/bin/rsnapshot beta

With that schedule you get six alpha snapshots a day, at 0, 4, 8, 12, 16 and 20 hours, plus a beta snapshot at 23:50. How many survive is entirely up to the retain lines in /etc/rsnapshot.conf. For three tiers the README shows beta at midnight, gamma on Saturdays at 23:00 and delta at 22:00 on the first of each month, which is a useful pattern to copy if you want monthly and weekly reach-back.

Restores are just files, which is the point and also the catch

Because each snapshot is a directory tree of hard links, a restore is a file copy: you find the file under the interval directory you want and copy it back. There is no repository format, no index and no restore command to learn, and the README notes the HOWTO covers setting things up so users can restore their own files. That simplicity is the strongest argument for rsnapshot over archive-format tools. The catch is that the snapshots are ordinary files on a filesystem, so anything that can write to the snapshot destination can damage them, and there is no integrity checking or content-addressed deduplication beyond hard links. Hard links also do not cross filesystems, so the snapshot root and the data it links against have to live on the same filesystem for the space saving to apply. And the deduplication is per-file: change one byte in a large file and the whole file is stored again in that snapshot. A database dump that is rewritten nightly at 40 GB will cost you 40 GB per snapshot, not 40 GB once.

link_dest and the unavailable-host failure mode

rsnapshot offers more than one way to create the unchanged-file links, and the README treats the choice as a real trade-off rather than a preference. With rsync 2.5.7 or later you may enable link_dest in rsnapshot.conf. Otherwise, on Linux, you should enable cmd_cp, especially if link_dest is not enabled. The README then states the limitation plainly: "currently link_dest doesn't do well with unavailable hosts." If a remote host is unreachable and link_dest is in use, there is no latest backup of that machine, and a full re-sync is required once it returns. Using the other methods preserves the last good snapshot and avoids the re-sync. That is a significant operational difference for anyone backing up laptops or hosts that are not always on. The README says the project hopes to streamline this in the future, which is an admission that it has not been fixed. There is a second historical compatibility note: GNU cp 5.9 or later caused problems with rsnapshot up to and including 1.2.3 when cmd_cp was enabled, resolved from 1.2.9 onward by stripping trailing slashes before running cp. Anyone reading old tutorials should know that advice about cmd_cp may predate the fix.

rsnapshot against borg, restic and plain rsync

Plain rsync is the closest comparison and the least flattering one for a single-snapshot use case. If you want one current mirror and nothing else, rsync alone is fewer moving parts: no config file, no cron wrapper, no interval rotation to reason about. rsnapshot earns its place only when you need history. Against borg or restic the difference is architectural. Those tools write into an archive repository with its own format, which typically brings deduplication at the block level and encryption, at the cost of a restore step that goes through the tool. rsnapshot writes plain directories you can browse with ls and copy with cp. If a nightly 40 GB dump is your problem, block-level deduplication in an archive format will beat hard links. If you want to hand someone a path and say "the file from last Tuesday is there", rsnapshot wins. rsnapshot also has no server daemon and no client agent, since it drives rsync over ssh, which matters on hosts where you cannot install extra software. The README itself points at rsnapshot-diff.pl in the repository root and at utils/rsnapreport.pl for reporting, so some of the tooling around the core script is deliberately separate.

Maintenance, licence and what upgrading costs

The repository is not archived, and the last push was on 2026-08-13, so the project is still receiving commits. Release history is uneven: 1.4.5 dates from 2022-12-27, and 1.5.1 arrived on 2025-01-27 after a release candidate the same day. That is a slow cadence, and it shows in the documentation: the README still carries compatibility notices about GNU cp 5.9 and rsync 2.5.7, versions from a much older era. The upgrade cost is low in one direction because the software is a single Perl script with no module dependencies, so there is nothing to compile against and no dependency tree to resolve. The cost is higher in the other direction because configuration semantics are what changed between releases, and the README sends anyone coming from 1.1.6 or earlier to docs/Upgrading_from_1.1. The licence is GPL-2.0, and the README opens with the standard disclaimer that rsnapshot comes with absolutely no warranty and that redistribution is welcome under certain conditions. For a tool that runs as root on a schedule and writes to your backup destination, that warranty position is worth reading before you rely on it as your only copy. Whether GPL-2.0 obligations affect your deployment depends on whether you distribute the software or a derivative, which is a question for your own counsel rather than something this article can settle.

Editorial conclusion

Adopt rsnapshot if you already run rsync over ssh against Unix hosts and want browsable, hard-linked snapshots driven by cron, with no daemon and no database. Do not adopt it if you need client-side encryption, Windows clients, or a backup that survives a lost link_dest host. Verify first that /etc/rsnapshot.conf exists or that you have copied /etc/rsnapshot.conf.default, that rsnapshot configtest passes, and that rsnapshot -t beta prints the rsync commands you expect before you let cron run them.

Frequently asked questions

Official sources

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