Backrest: a cross platform backup orchestrator and WebUI for restic

Hello restic community and happy New Year!

I’m a long time user of restic and today I’m posting to share a restic-ecosystem WebUI I’ve been working on in recent months that I’m calling Backrest. I created Backrest because I wanted a backup tool with the fantastic capabilities of restic (fast, cross platform, reliable, well supported by a large community!!) that have lead me to use it on all of my systems but also with an easy to use remote-accessible WebUI across all of my platforms.

Backrest aims to take away the burden of setting up and managing restic backups by providing a simple to use featurefull web UI that supports both scheduling backup operations as well as browsing and restoring from existing backups. Backrest is shipped as a self-contained and light weight (<20 MB on all platforms) binary with no installation dependencies. It is my hope that Backrest fills a hole in the restic ecosystem in that it is suitable for both backups of headless systems (e.g. a web accessible UI for your NAS) and interactive devices (e.g. on a personal laptop). Backrest additionally tackles all problems associated with restic automation e.g. it is both a browser and a backup scheduler. I’m using Backrest myself to backup a NAS running Linux, a Mac laptop, a Windows laptop, and a Linux development machine.

Philosophically Backrest is a fairly thin wrapper around restic. It aims to create snapshots that are easy to view in the UI but that can also be easily manipulated out-of-band with the restic cli (without breaking anything!). Each operation Backrest performs on your behalf will be presented in the UI with visible status information and error messages.

Backrest’s WebUI features:

  • Creating restic repositories
  • Creating backup schedules (backrest orchestrates the backup operations, no need to setup your own cron jobs, systemd timers, or launchd agents)
  • Browsing backup operation history
  • Browsing snapshot contents and restoring files from the UI (e.g. no need to fiddle with the cli in a high-stress moment when you’ve lost data!).
  • Darkmode & Lightmode UI matching system settings.

Operational details

  • Restic repositories are a native concept in backrest and any repo type supported by restic is supported by backrest (local, SFTP, S3, B2, etc).
  • Backrest adds a concept of a plan which is a list of directories to backup along with a schedule (expressed as a simple cronexpr), rentention policy (per restic forget), and any exclusion rules or other optional flags for the operation. This is how you configure what to backup and when.
  • Multiple plans can optionally share a repository such that you can have differential backup schedules for different directories on your machine. This is implemented simply using restic tags and is easily understood when browsing the repo with the restic CLI (should you feel the need to do so! Backrest can be used for most common browsing).
  • Scheduled health operations: prune and forget are run automatically with configurable frequency and retention. By default a prune operation is run every 7 days. Forget runs after every backup.

Downloading and installation: check out more details at https://github.com/garethgeorge/backrest. Releases are provided with GitHub actions (check the releases page) and install scripts for systemd / launchd services are bundled in each release for Linux and MacOS. An example with docker-compose config is also provided.

Wrapping up! I’m hoping that Backrest will be useful to others in the restic community as well and appreciate any feedback from the community! I’ll be using this to backup my systems and for my family, I aim to be active with issues + feature work and in getting out new versions with future restic releases.

Screenshot showing operation history tree & snapshot browser for a recent backup on my Linux host

11 Likes

Very cool! Looking forward to seeing how this evolves.

How do you do scheduling? Does it require that the application itself is always running, or does it somehow use the system’s scheduling features? If the former, is there some support for making the application run automatically on boot, or does one have to log in the user account and have the application in the autostart of the account?

Appreciate your interest! Scheduling is done with Backrest always running in the background. Backrest has an in-process task queue backups based on schedules, cronexpr is just used as a syntax for denoting schedules in the backrest config. Backrest idling in the background is a big element of why I’ve also taken pains to keep the binary small & to avoid any big in memory datastructures. Backrest should be very lightweight between backups.

For launching on startup I actually have some short guides on the README page for setting up systemd timers (or a launchd agent in the case of MacOS) to have backrest launch on startup. There’s also an install.sh script in the release that will copy backrest into /usr/local/bin and setup a startup task for it.

this looks worth it to try just for restoring files. i like how you can look into the snapshots.

it could be an easy way to periodically check your backups by restoring a file or two.

very cool!

1 Like

I finally had some time to try this project out and I have to say it is impressive. Deployment and configuration was very simple, it all just worked with minimal fuss (I went with a docker-powered containerised setup for testing). I have to echo what arkadi said as well about the ease of viewing and restoring individual files/folders; that is a very useful feature.

I did have a question about how you schedule restic prune though, if you’ll indulge my curiosity. I noticed that a forget task seems to be scheduled every time a backup is run, but only if the retention policy dictates it is necessary. Prune doesn’t seem to work quite the same though, in testing so far I only saw it run once, after the first “forget” task. Is there a limit per time period that prune can be triggered in or something similar?

Anyway, very nice work, thanks for sharing it! :slight_smile:

Glad it’s working well for you!

Prune scheduling (and the rules around other operations) are something I’d like to document a bit more explicitly – it’s a good question! At the moment the rules are

  • Forget runs after every backup, the operation is hidden if no action is taken e.g. no snapshots are removed.
  • Prune runs automatically every 7 days OR when you click the “Prune Now” button.

For a bit more control there is a “prunePolicy” property of the repo that may be set in the config, e.g.

{
   "id": "your_repo",
   ... other repo fields ...
   "prunePolicy": {
      "maxFrequencyDays": 30,
   }
}

should reduce the frequency to monthly. Exposing this in the UI is high on the todo list. You can find a few other hidden fields that let you tweak this in the proto definitions of the config structure.

1 Like

Released Backrest v0.10.0

New Features

  • Restic dependency updated to v0.16.3 (latest release).
  • Prune policy configurable in the repo UI (e.g. control the frequency of prune operations).
  • GPG key verification for restic installer: when Backrest is managing your restic installation it will now verify the download against a known GPG key for restic releases using the same approach as restic self-update

Available at: Release v0.10.0 · garethgeorge/backrest · GitHub

This looks nice. I’d love to use a secrets manager to read passwords from instead of a password being written to disk

1 Like

This is a pretty interesting point. At a minimum I’ll look at updating Backrest to require 600 permissions for the config file (e.g. readable / writable only for the current user).

In general, if an adversary has access to your filesystem and can read everything you’re typically in trouble. Best defense against ransomware is going to be using an append only repo and disabling forget / prune. I’ll make sure to add an option for this (right now backrest is perhaps too opinionated in that it always expects to run these health operations).

WRT a secret manager, I wonder if supporting encrypted config would accomplish this w/a config decryption key passed by environment variable? Perhaps you can open an issue on the GitHub repo to discuss a bit more of the UX!

1 Like


First thanks for your work. the description of the what this program can do excites me. i am mainly windows user but also have UNRAID, Proxmox, play some dockers and Linux VM & LXC.

now, i have problem trying to install in windows.
i added backrest folder to windows environment variable path and run backrest in cmd but cant launch it.
do i need to manually download or set the restic.exe folder? because for windows, it will not be at the folder it try to find. it is always at more convenient folder of “c:\restic”

same error even if i put backrest in the adviced location

Update:
i manually copied restic.ext and renamed it to specific name (0.16.3) as shown in cmd that backrest if finding, then it works. i guess this make things very difficult for any user to install, especially whenever new restic version come out.

Suggestion:
just look for restic.exe in few default folder including C:/restic or even C:/rclone

Oops – sorry you ran into this! Windows support is definitely experimental so support will be a bit more sporadic (and may break occasionally) but I am using it on one of my devices for the sake of beta testing my own code and whatnot to try to improve that overtime / generally get a stable release out.

With respect to your issue – it definitely looks like I broke the Windows installer in the latest release, I suspect it’s a simple fix. I’ll aim to get some test coverage setup for Windows. In the meantime, I think manually installing restic to that path as you’ve done is a good workaround. I’ve created Fix windows installer · Issue #58 · garethgeorge/backrest · GitHub to track this.

no problem. small issue to fix. manage to figure out an obvious fix. do keep up the good work though.
sounds like windows is not the main focus for backrest. usability in windows wise, i guess it will only improve over time when you add more discription. for “Add plan”, it will be great to able to read from a file for inclusion list and exclusion list like the normal restic can do. not sure whether this “add path” able to work for a file.

in windows wise, i am not sure whether backrest will run in background of scheduled backup. This is because in windows, i need to launch backrest through cmd to access the web-ui, as soon as the cmd is closed, web-ui is no longer accessible. this make me thing whether is there even any schedule that will work in the background

Configure it as a service. Myself I use nssm for this.

2 Likes

Thanks all for the feedback and appreciate the nssm suggestion – I’ll test this out and see if I can provide some instructions for Windows setup on the project wiki!

Posting to announce a new release and highlights from the release log –

Released Backrest v0.11.1

Features:

  • update to restic 0.16.4
  • added support for user configurable hooks (e.g. send notifications or execute shell scripts before / after backup operations or errors)
  • add user configurable command hooks for backup lifecycle events (#60) (9be413b)
  • authentication for WebUI (#62) (4a1f326)
  • implement discord hook type (25924b6)
  • implement gotify hook type (e0ce655)
  • support keep-all retention policy for append-only backups (f163c02)

Bug fixes

  • added API test coverage and fixed some minor bugs
  • stats not displaying on long running operations
  • fixed windows support for downloading and installing restic

Available at Releases · garethgeorge/backrest · GitHub

I think you made a typo , the current restic version is 0.16.4.

I don’t upgrade to newer restic versions until after multiple point releases to avoid bugs. Is there a way to select which restic version to use ?

Edit : Nevermind, use environment variable

I cannot set BACKREST_PORT=127.0.0.1 via nssm. Works fine from powershell, maybe it’s related to “.” in the ip ?

$env:BACKREST_PORT=127.0.0.1; $env:BACKREST_CONFIG='D:\Backrest\config.json'; $env:BACKREST_DATA='D:\Backrest\data'; backrest

Consider implementing this issue : Allow modifying more settings from config file or command line parameters, settings which are currently set via environment variables · Issue #77 · garethgeorge/backrest (github.com)

Hi!
I must say this looks really nice, very promising!
I tried installing on my NAS via docker, but I cannot connect to the repo, as there does not seem to be an rclone binary in the container. Would it be possible to add this please?
Also, there does not seem to be any shell included, so going into the container via docker exec /bin/sh for doing stuff under the hood, for example configure and test rclone connection once it exists, is not doable, would you consider adding this to your container?
Thanks a lot!