Self-host Backrest on a VPS: encrypted backups, no command line

Backing up a VPS is the task everyone puts off, because it returns nothing until the day it returns everything. Provider snapshots are convenient, but they copy the whole machine to the same provider in the same place: they protect against your own mistakes, not against losing the account or an incident on the infrastructure. And a snapshot will not give you back one file that was overwritten this morning.

The reference open-source answer is restic: end-to-end encryption, deduplication, incremental snapshots, and support for virtually every object store. Its only weakness is ergonomic — it is a command-line tool. Adopting it in practice means writing your own scripts, cron entries, retention policy, periodic pruning and monitoring. Many people stop after the first script, and nobody notices when it quietly stops running.

Backrest is lightweight, but a few hardware and software prerequisites are worth checking before deploying. On the server side, 512 MB RAM is the functional minimum — enough for a machine dedicated to backups; if the VPS also runs other active services, 1 GB is more comfortable. The version of restic bundled in the Backrest Docker image is kept current by design, but if you manage restic independently, make sure you are on restic ≥ 0.16.0: older versions do not handle certain JSON retention policies and may silently ignore --keep-* rules.

Backrest exposes its UI on port 9898 (TCP). That port must be open in your VPS firewall (ufw allow 9898/tcp or equivalent), but should not be publicly reachable without authentication: on first start, restrict it by source IP while you create your admin account. Finally, the Backrest data directory — /var/lib/backrest in the ServOrbit recipe — requires write access for the containerised process: a Docker volume accidentally mounted read-only will silently fail to save configuration changes.

Backrest is a single Go binary that bundles restic. It runs in one container with no database and no external cache: its configuration lives in a JSON file and its state in a data directory. That is the opposite of enterprise backup stacks, and it is what makes it a sensible fit for a modest VPS.

The direction of the encryption is what matters. restic encrypts every snapshot locally, on your server, before a single byte leaves it: the destination only ever receives opaque blocks. The repository password is the key, and you alone hold it — which means the storage can be a cheap, untrusted provider without any confidentiality problem, but also that losing that password makes the backups permanently unreadable. That is the explicit trade-off of any client-side encryption.

In the ServOrbit recipe, the host's /home, /root and /etc are mounted read-only under /host inside the container. Backrest can therefore back up the server's data and configuration while being structurally unable to modify them.

Restoring in Backrest works at two levels depending on the granularity you need.

From the web interface: open the Snapshots tab of your plan, select a snapshot by date, navigate the file tree and click Restore for any file or folder. Backrest triggers a restore to the destination path you specify — for example /tmp/restore-test/ to avoid overwriting the live file.

From the restic CLI (useful for large or scripted restores): enter the container with docker exec -it backrest sh, then run restic -r <your-repo-url> restore latest --target /tmp/restore/. To restore a specific path rather than the whole snapshot, add --include /host/home/user/project — restic only restores that subtree. After a restore, validate the source snapshot's integrity with restic check --read-data-subset=5%: this option checks a random sample of data blobs (not just metadata) without having to download everything.

Silent cron failure. If the plan never triggers despite a correct schedule, confirm the Backrest container is running (docker ps) and that its internal clock is synchronised with the host (pass --env TZ=Europe/Paris or your timezone equivalent when creating the container). A clock offset can let the trigger window pass with no error logged.

wrong password or no key found error. This error appears when the password you enter does not match the key stored in the repository. It can also mean the repository was initialised a first time with a different password — each restic repository has only one active key set. Check that you have not got a trailing space or invisible character in a copy-pasted password. If you have lost the password, the repository is permanently unreadable — that is the price of client-side encryption.

Insufficient storage space on the backend. Backrest shows a repository is full error or similar when the bucket quota is reached. Enable automatic prune in your plan to prevent old snapshots from accumulating beyond the retention policy. On Backblaze B2, you can also configure a lifecycle rule on the bucket to automatically delete objects flagged by restic as deleted (restic forget only removes blobs after a subsequent prune).

Backrest no longer responds on port 9898. First confirm the container is running (docker ps), then that the port is bound (ss -tlnp | grep 9898). If the container is in a restarting state, check the logs with docker logs backrest --tail 50 — a corrupted JSON configuration file is the most common cause after an abrupt shutdown.