Backrest

Web UI and orchestrator for Restic backups

Backup & Recovery ★ 7.4k stars Easy setup GPL-3.0

Backrest is a web-based backup orchestrator built on top of Restic, adding scheduling, monitoring, and a friendly interface. It targets users who want Restic's power with a GUI. It is deployed via Docker or a binary.

Key features

  • Web UI for Restic
  • Scheduling and retention policies
  • Backup health monitoring
  • Notifications

Pros & cons

Strengths

  • Makes Restic approachable
  • Good scheduling
  • Lightweight

Trade-offs

  • Young project
  • Depends on Restic underneath

Backrest replaces

Last reviewed Sep 13, 2026 · 756 words

One Docker container, one browser tab, and every restic feature you were previously driving with a cron job and a shell script: that is Backrest. It does not replace Restic; it bundles the real restic binary and calls it, so the repository it creates is a standard restic repository you can read with the CLI from any machine. That detail is the reason to trust a project that is only 2 years old with your backups: if Backrest vanished tomorrow, your data would still be sitting in a format with a decade of history.

What Backrest adds to plain restic

Restic on its own has no scheduler, no retention runner, no dashboard and no notifications. People bolt those on with cron, restic forget --prune in a script, and a Healthchecks ping. Backrest replaces that assembly with plans: a plan is a set of paths, a repository, a cron schedule, a retention policy and a list of hooks. The UI shows every snapshot with size and duration, lets you browse files inside a snapshot and restore a single directory to a chosen path, and surfaces failed runs in red rather than in a log nobody reads. Hooks fire shell commands or notifications to Discord, Slack, Gotify, Shoutrrr and generic webhooks on start, success and failure.

The compose file that covers 90 percent of installs

services:
  backrest:
    image: garethgeorge/backrest:latest
    ports:
      - "9898:9898"
    volumes:
      - ./backrest/data:/data
      - ./backrest/config:/config
      - ./backrest/cache:/cache
      - /srv:/userdata/srv:ro
      - /mnt/backups:/repos/local
    environment:
      - BACKREST_DATA=/data
      - BACKREST_CONFIG=/config/config.json
      - XDG_CACHE_HOME=/cache
      - TZ=Europe/Dublin
    restart: unless-stopped

Mount what you want backed up read-only under /userdata, and either mount a local disk for the repository or point the repository at a remote. Backrest supports every backend restic does, so S3, Backblaze B2 and SFTP work with credentials typed into the repository's environment section, and any rclone remote works through restic's rclone backend for the long tail of providers. The first visit asks you to set a username and password; set them, because the UI can restore files to arbitrary paths inside the container.

Retention, prune and check are three separate schedules

This is the setting people get wrong. Retention (keep 7 daily, 4 weekly, 6 monthly) runs after each backup and only marks snapshots as forgotten. Prune actually reclaims space and is expensive on large repositories, so Backrest lets you schedule it separately per repository; weekly is fine for a home NAS. Check verifies repository integrity and can read a percentage of pack data; I set it to run monthly and to read 10 percent. Skip check and you find out about bit rot on restore day. Restic needs about 256 MB of RAM for small repositories and scales with the number of files, so a 2 TB photo library will push the container past 1 GB during prune; that is restic behaviour, not Backrest's.

Do the restore before you need it

Pick a directory, open the latest snapshot in the UI, restore it to /userdata/restore-test, and diff it against the source. Ten minutes, and it also proves the repository password you stored in Backrest's config is the one that works. The config file in /config contains repository passwords and cloud credentials in plain text, so it needs its own backup to somewhere other than the repository it protects. The 3-2-1 piece covers where the second and third copies should live.

Where Kopia and Borg still win

Kopia ships its own server mode and a desktop client, and handles multi-machine setups with per-client policies more naturally; Backrest is one orchestrator per host. BorgBackup has a longer track record and slightly better deduplication on some workloads, but no first-party web UI at all. Restic's cloud-backend support is broader than Borg's, which is usually the deciding factor for anyone backing up to object storage; the Borg vs Restic comparison goes through it.

What I'd do

Backrest on every Docker host, one plan per data set, repository on B2 or a second box over SFTP, retention 7/4/6, prune weekly, check monthly at 10 percent, Discord hook on failure only. Copy config.json into your password manager. Then run one restore test now and one every quarter. For a beginner it is the fastest path I know to an encrypted, deduplicated, off-site backup that also tells you when it broke.

Compare Backrest

21 head-to-head comparisons.

Similar backup & recovery apps