[Note] | 17 août 2026
Backrest Restic Systemd Linux SysAdmin

How to keep Backrest running as root after an update

Backrest's install.sh regenerates the systemd unit on every run and silently drops back to your login user unless you pass --root.

If Backrest needs to run as root on your box (e.g. some plans read root-owned paths like /root or system config), always update with:

curl -fsSL https://raw.githubusercontent.com/garethgeorge/backrest/main/install.sh | sudo bash -s -- --root

The --root flag is not optional past the first install — skip it and the service silently switches back to your login user on every update.

Why

The official installer doesn’t just drop a new binary in /usr/local/bin, it regenerates the systemd unit file on every run. Run it as sudo bash without --root, and it picks up $SUDO_USER instead of root, rewriting the unit to User=myuser.

Backrest then restarts as myuser, reading its config from ~/.config/backrest and ~/.local/share/backrest instead of /root/.config/backrest. The web UI comes back with only one repo and none of the real plans — looks like data loss, but nothing is actually deleted. It’s just reading from the wrong $HOME.

The README does mention it, in one line easy to miss:

The service runs as your user by default (so config and data live under your $HOME). To install as root instead, pass --root.

How to confirm after an update

journalctl -u backrest -n 100 --no-pager

Check log_dir in the output — it should still point to /root/.local/share/backrest/processlogs. If it jumped to /home/<you>/.local/share/backrest/processlogs, the unit got reset; stat -c '%y' /etc/systemd/system/backrest.service will match the update timestamp exactly.

Fix it by re-running the install command above with --root. That regenerates the unit with User=root/Group=root, and everything reappears — plans, schedules, repos.

Worth knowing

  • Nothing was deleted: the “missing” plans were sitting untouched in /root/.config/backrest/config.json and /root/.local/share/backrest/ the whole time.
  • The installer gives no warning that it just switched the service’s user — worth checking journalctl -u backrest after any update to confirm log_dir still points where you expect.
  • Same applies to any tool with a curl-pipe installer that manages its own systemd unit: assume it can reset ownership/user flags to defaults unless you pass the same flags every time.