Backrest

What is Backrest?

Backrest puts a browser UI and scheduler in front of restic, so you get the storage backends and deduplication of restic without writing shell scripts for scheduling, pruning and retention.

Best for

Using restic without learning its command line

Why choose Backrest

Backrest is what restic looks like with a user interface. It wraps the same storage backends and deduplication in a web UI with a scheduler, so retention, pruning and backup plans become settings rather than shell scripts you have to write and remember to test. It shows the history of every backup run, which is the single most useful thing to have when you are wondering whether last night's job actually completed. Multiple repositories can be managed from one place, and restore is a point-and-click operation rather than a sequence of flags. For someone who likes what restic does but does not want to maintain a fragile cron script around it, it removes exactly the part most likely to be neglected.

Replaces

• Duplicati
• Arq Backup
• Backblaze

Key features

• Graphical repository and plan management
• Schedules, retention policies and pruning
• Restore browsing from the browser
• Notification integrations

What to watch out for

It is a front end, so anything it cannot express is still a limitation of restic underneath — the same repository password risk, the same pruning cost and the same per-file overhead. Running it as a service means another container with access to your backup destinations and your source data, which deserves the same security consideration as the backup itself. The project is younger and smaller than restic itself, so unusual problems have fewer documented answers. It mounts the restic binary and configuration paths, and mistakes there produce confusing failures. It also needs somewhere to keep its own configuration, which itself needs backing up.

How to deploy

• Single Docker container
• Add repositories and plans in the UI
• Mount a persistent config volume

Getting started

Deploy it with persistent storage for its own configuration, because losing that loses your job definitions and schedules even though the repositories survive. Reuse an existing restic repository if you already have one — the formats are compatible — rather than starting over. Set the schedule and retention together in the UI, then run one job manually and watch it complete rather than trusting the configuration. Configure notifications so a failed run reaches you instead of going unnoticed for a month. Finally, do a restore through the interface, because that is the workflow you will need most and it is worth knowing it works before an emergency.

Typical setup

A container with persistent storage for its own configuration, managing one or more restic repositories on object storage or a local destination. The repository password is recorded somewhere durable and separate from the host. Jobs are defined in the interface with a schedule and retention policy set together, and notifications are configured so a failed run reaches a human instead of going unnoticed. One restore has been performed through the UI, because that is the workflow most likely to be needed under pressure. The configuration directory is included in whatever backs up the container host itself.

Who should look elsewhere

If you are already comfortable with restic on the command line and your existing scripts are maintained, the UI adds a container and a dependency for convenience you may not need. It is also not a monitoring or verification system on its own — it will not tell you that your restores are corrupt, and a backup you have never restored remains unproven regardless of how nice the dashboard looks. And if your backup needs are a single directory to a single destination, a scheduled rsync is simpler than either tool.

Project health

• GitHub stars: 7,440
• Last code push: 2026-09-21
• Open issues: 375
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.