Restic
Fast, secure backups to almost any storage
What is Restic?
Restic writes encrypted, deduplicated snapshots to a local disk, SFTP server, or dozens of object storage providers. A single static binary, no server component, and snapshots that can be mounted or restored selectively.
Best for
Encrypted backups straight to object storage
Why choose Restic
Restic gets the hard parts of backup right and stays out of your way everywhere else. It writes encrypted, deduplicated, content-addressed snapshots to almost any destination — a local disk, an SFTP server, or dozens of object storage providers including the cheap archival tiers that make offsite backup affordable. It is a single static binary with no server component, so it deploys anywhere and there is no daemon to keep alive. Deduplication is global across snapshots, which means a backup of a mostly-unchanged dataset costs almost nothing in storage or bandwidth after the first run, and any snapshot can be mounted as a filesystem or restored selectively. Verification is built in, which addresses the question that matters most: whether the backup can actually be restored.
Replaces
- Backblaze
- Duplicati
- Arq Backup
Key features
- Single static binary, no server required
- Deduplication across all snapshots
- Backends for SFTP, S3, B2, Azure, GCS and more
- Mount snapshots to browse and restore individual files
What to watch out for
Restic is a command-line tool and expects you to bring your own scheduling. Retention and pruning are separate commands you have to configure, and forgetting to run them is the usual way a repository grows until storage costs become a problem — pruning also rewrites data and periodically needs more time and bandwidth than a normal backup. The repository password is the whole security model: lose it and the data is unrecoverable, with no recovery mechanism by design. Concurrent access to one repository from multiple hosts is supported but needs care, since two prunes at once can conflict. Rate limits and per-file overhead mean millions of small files are slower than a plain rsync.
How to deploy
- Install the binary on the machine to back up
- Initialise the repository with a password file
- Schedule backup and forget in cron
Getting started
Create the repository first, then store the password somewhere that is not the machine you are backing up — a password manager plus a written copy in a safe is the honest recommendation, because losing it is unrecoverable. Run one backup manually and confirm the snapshot appears, then add a schedule. Configure a retention policy and a prune schedule together rather than adding pruning later, when the repository has already grown. Enable the built-in integrity check on a periodic schedule and make sure it actually runs. Most importantly, restore a file to a scratch directory and open it, because that is the only proof the setup works.
Typical setup
A single static binary on the machine being backed up, with a repository on one of the well-supported object storage providers — that combination is what makes offsite backup affordable rather than aspirational. The repository password is stored in a password manager with a written copy somewhere durable and separate, because losing it is unrecoverable. A scheduled backup runs nightly, retention and prune are configured together rather than added later, and an integrity check runs on a periodic schedule. A restore of a single file into a scratch directory has been performed at least once, because that is the only real proof the setup works.
Who should look elsewhere
Not for anyone who wants a graphical backup product with a scheduler and a restore wizard — Restic assumes you are comfortable in a shell and will write the automation yourself. Avoid it if you cannot keep the repository password safe, because a forgotten password means a pile of encrypted noise rather than a backup. And if your working set is small and changes rarely, the deduplication buys little, making a simpler copy-based approach perfectly adequate.
Project health
- GitHub stars: 36,371
- Last code push: 2026-10-01
- Open issues: 607
- Status: actively developed
Figures pulled from the GitHub API and refreshed periodically.