rsnapshot

Filesystem snapshots built on rsync and hard links

Backup & Recovery GPL-2.0 Intermediate ★ 3,686 stars

What is rsnapshot?

rsnapshot uses rsync to copy files and hard links to make each run look like a full snapshot while only consuming space for what changed. Simple, transparent, and easy to inspect with normal tools.

Best for

Simple local snapshots you can browse like a folder

Why choose rsnapshot

rsnapshot is the simplest possible honest answer to snapshot backups: it uses rsync to copy files and hard links to make each run appear as a complete snapshot while only consuming space for what changed. Because it is built from standard Unix tools, every snapshot is a directory you can browse with normal commands, copy from with cp, or share over the network — there is no repository format, no special client, and no recovery step beyond finding the file. That transparency is worth a lot in an emergency, when the last thing you want is a tool that needs to work before your data is accessible. Configuration is a single file describing sources, destinations and how many snapshots to keep at each interval.

Replaces

  • Time Machine
  • Backblaze
  • Borg

Key features

  • Hard-link based snapshots that look complete
  • Configurable hourly, daily, weekly retention
  • Backs up local and remote hosts over SSH
  • Plain files readable without special software

What to watch out for

Hard links only work within one filesystem, so the snapshot destination must be on a single volume and the source must be reachable in a way that preserves the semantics rsync expects. Because snapshots are visible directories, anything that can write to the destination can corrupt or delete them, which makes the target an obvious ransomware target unless it is properly isolated. There is no encryption and no deduplication beyond what hard links give you, so the space saving is real but far smaller than Borg's or restic's. Rotation is by deleting old trees, which is simple but offers no integrity verification. Restoring many small files can be slow because it is a plain file copy.

How to deploy

  • Install from package manager
  • Configure sources and retention in the config file
  • Schedule via cron

Getting started

Put the destination on its own volume with enough space for several full-looking snapshots, and make sure the source paths are consistent so the hard-linking works as intended. Configure intervals that match how far back you need to reach — hourly, daily, weekly, monthly — and keep the counts modest until you see how much space each level consumes. Exclude caches, temporary directories and anything huge and reproducible, since this tool does not deduplicate content. Restrict write access to the destination tightly, ideally making it writable only by the backup job's account, because visible directories are visible to whatever else runs on that machine. Test a restore by copying a file back out, and keep a copy of the configuration with the snapshots.

Typical setup

A configuration file describing sources, a destination on its own volume, and interval levels with retention counts that have been checked against real space consumption. Caches and temporary directories are excluded, and the destination is writable only by the backup account because every snapshot is a plain visible directory. The configuration is kept with the snapshots so a rebuild is possible. Write access is restricted tightly, and a restore has been performed by copying a file back out and confirming it opens, since there is no repository format to stand between you and the data.

Who should look elsewhere

Do not use it for offsite or untrusted storage, because the snapshots are plain directories with no encryption and anyone with access can read your files. Avoid it if you need content-level deduplication, encryption or verification, all of which faster and more efficient tools provide. And if your destination must be shared with other services that write there, the whole-tree deletion model means a mistake elsewhere can take the backups with it.

Project health

  • GitHub stars: 3,686
  • Last code push: 2026-08-13
  • Open issues: 58
  • Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.

More in Backup & Recovery