RE

Restic

Fast, secure, efficient backup program

Backup & Recovery ★ 36.2k stars Medium setup BSD-2-Clause

Restic is a fast and secure backup program that creates encrypted, deduplicated snapshots to many storage backends. It targets users and admins who want reliable command-line backups. It is deployed as a single binary.

Restic setup guides & articles

Hands-on coverage of Restic from the blog.

Key features

  • Encrypted deduplicated snapshots
  • Many storage backends
  • Fast incremental backups
  • Single self-contained binary

Pros & cons

Strengths

  • Strong encryption
  • Efficient deduplication
  • Wide backend support

Trade-offs

  • Command-line only
  • No built-in scheduler

Restic replaces

Last reviewed Aug 26, 2026 · 792 words

export RESTIC_REPOSITORY=s3:https://s3.eu-central-003.backblazeb2.com/my-backups
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /home /etc /srv/docker --exclude-file=/root/.restic-exclude
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
restic check --read-data-subset=5%

That is a complete, encrypted, deduplicated, off-site backup. Restic's entire pitch is that the tool is one binary of roughly 25 MB and the mental model is five verbs. What it does not give you is a scheduler, a dashboard, or any forgiveness if you lose the repository password, and those three gaps are what the rest of this guide is about.

The password is the backup

Every byte in a Restic repository is encrypted with a key derived from your password. Lose the password and the repository is a pile of random blobs; there is no recovery, no support ticket, no back door. So the password must be stored somewhere that survives the total loss of the machine being backed up: in your password manager, and printed. Use a file (RESTIC_PASSWORD_FILE) rather than the environment variable in scripts so it does not leak into process listings and shell history. Test the stored copy by restoring from a different machine once; if you have only ever typed it from memory, you have not tested it.

Retention: forget is not prune

restic forget removes snapshot references according to the keep policy; the data stays until prune rewrites the pack files and drops what nothing references. Run them together with --prune as above, but understand that prune is the expensive step: it reads the index, may download and repack data, and on a slow backend it can take an hour for a 500 GB repository. Weekly is plenty. The policy above keeps 7 daily, 4 weekly, and 12 monthly snapshots, about 23 restore points covering a year, for something like 1.2 to 1.5 times the live data size thanks to deduplication. Add --keep-yearly 3 for records you are obliged to keep.

Pick a backend by what you will still trust in 5 years

Restic speaks to local disks, SFTP, S3-compatible object storage, Backblaze B2, Azure, Google Cloud, its own rest-server, and via rclone to anything rclone supports, which is everything else. For a homelab the sensible combination is two repositories: one on a local drive or a second machine for fast restores, one on B2 or an S3-compatible provider for the disaster case. B2 costs about 6 dollars per TB-month at last check and is the reason Restic is the standard answer in the Backblaze alternatives discussion: same storage, your own encryption. The 3-2-1 backup rule for self-hosters covers the layout in detail.

Scheduling is your job, and Backrest does it well

There is no daemon. A systemd timer or cron entry running a 10-line script is the traditional answer and works fine, but it means no UI, no notification on failure unless you write one, and no easy way to browse snapshots. Backrest wraps Restic in a small web interface that handles schedules, retention, hooks for notifications, and point-and-click restores while using the standard repository format, so nothing is locked in. For a single server I use a timer; for a household with 3 machines backing up to one repository, Backrest is worth its 50 MB.

Memory scales with the repository index rather than with data size: the 256 MB in the listing is fine for a few hundred GB, while multi-terabyte repositories with millions of files can push a prune past 1 GB. Run those on the server, not the Pi.

Restic or Borg

The two are close. Borg is a little more space-efficient and has been around longer; Restic runs on Windows, talks to cloud object storage natively rather than needing a Borg install on the far end, and has a simpler key model. If your target is a rented box running SSH, either works. If your target is B2 or S3, Restic with no middleman. The BorgBackup vs Restic comparison goes through the detail.

What I'd do

Two repositories, one local and one on B2, both with the same 7/4/12 policy. Back up nightly from a systemd timer that also runs restic check weekly with --read-data-subset=5% so silent corruption on the backend gets caught. Password in the password manager and on paper. A test restore of one directory every quarter, calendar reminder set. Restic is the best-value backup tool a self-hoster can pick in 2026, provided you supply the discipline it deliberately leaves out.

Compare Restic

23 head-to-head comparisons.

Similar backup & recovery apps