Where can Backrest store the backups?

Anywhere restic supports, which includes every rclone remote: Amazon S3, Backblaze B2, Wasabi, MinIO, Azure Blob, Google Cloud Storage, SFTP/SSH, or a local or network-mounted disk. Backblaze B2 is the usual choice for a VPS — inexpensive, S3-compatible and well outside your server's own failure domain, which is the whole point of an off-site backup.

Is the backup encrypted, and who holds the key?

Yes, and you do. restic encrypts every snapshot client-side, on the VPS, before anything is uploaded — the storage provider only ever receives opaque blocks. The repository password is the key. Store it in a password manager: if you lose it, the backups are mathematically unrecoverable, and neither ServOrbit nor the storage provider can restore access.

How much disk space and RAM does Backrest need?

The container itself is small — under 100 MB RAM at idle and a few hundred megabytes of image and cache. The real cost is at the destination, and deduplication makes it modest: after the first full snapshot, subsequent runs typically upload only the changed blocks, so a 20 GB server with months of daily retention often stays in the low tens of gigabytes.

Can Backrest back up files outside its container?

It backs up what is mounted into it. The ServOrbit recipe mounts /home, /root and /etc from the host read-only under /host, which covers user data and system configuration on a typical VPS. To protect other paths — a data directory, a Docker volume — add the corresponding read-only mount to the compose file and it appears in the plan's path picker.

How do I know a backup actually ran?

Backrest shows the status and history of every plan in the UI, and it runs scheduled `check` operations that verify repository integrity rather than merely reporting that the job started. For active alerting, configure a hook on failure pointing at a webhook — a self-hosted ntfy topic works well and puts a failed backup on your phone the same night, which is how you avoid discovering a three-month-old broken job during a restore.

Deploy and manage modern applications.

Backrest

Encrypted, deduplicated VPS backups with a web UI — restic's power without the command line. Single container, under 100 MB RAM.

1 GB RAM 1 vCPU Port 9898 Available

Tech stack

DockerGorestic

Minimum RAM1 GB

Minimum CPU1 vCPU

Default port9898

Compatible OSChoice of Linux distributions

Backrest is an open-source web UI and orchestrator for restic (~7 k GitHub stars, GPL-3.0, v1.14.1). restic is the reference open-source backup engine — encrypted end-to-end, deduplicated and incremental — but it is a command-line tool, which means cron entries, shell scripts and a lot of remembered flags. Backrest wraps it in a browser interface: create repositories, define backup plans with a schedule, browse snapshots as a file tree and restore individual files or whole directories, all without typing a restic command.

Self-hosting Backrest on a ServOrbit VPS is what turns a server into a server you can actually lose. Every snapshot is encrypted client-side before it leaves the machine, so the destination never sees your data in the clear — you can safely push backups to Backblaze B2, Amazon S3, Wasabi, an SFTP box or any of the dozens of rclone remotes restic supports. Deduplication means the second snapshot of a 20 GB server typically costs a few hundred megabytes, so retention of months of history stays affordable.

Backrest runs as a single Go binary in one container using under 100 MB of RAM, with no database and no external dependency. It handles the operational chores restic expects you to script yourself: cron-style scheduling, retention policies (keep N daily, weekly, monthly), automatic `prune` and `check` runs to keep the repository healthy, and hooks that fire on success or failure — point one at your ntfy topic and a failed backup pushes to your phone instead of dying silently in a log.

Key features

Web UI over restic — create repos, run backups, browse snapshots as a file tree and restore files or folders without a single command line.

End-to-end encryption: every snapshot is encrypted client-side before upload, so the storage provider never holds readable data.

Deduplicated and incremental — only changed blocks are uploaded, so months of retention typically cost a fraction of the source size.

Any restic backend plus every rclone remote: Amazon S3, Backblaze B2, Wasabi, MinIO, SFTP, Azure, Google Cloud Storage or a plain local disk.

Cron-style scheduling per plan, with retention policies (keep N hourly / daily / weekly / monthly / yearly).

Automatic repository maintenance — scheduled `prune` to reclaim space and `check` to detect corruption before you need the backup.

Hooks on backup start, success and failure — send the result to ntfy, Discord, Slack or any webhook, or run a shell command (e.g. dump a database before the snapshot).

Multiple repositories and multiple plans side by side — back up /home hourly to B2 and /etc daily to a local disk from the same instance.

Single Go binary, under 100 MB RAM, no database — restic is the only dependency and it ships in the image.

When to use this solution?

1

Off-site backup of a production VPS

Schedule a nightly encrypted snapshot of /home, /etc and your application data to Backblaze B2 — a few euros a month for months of retention thanks to deduplication. Because encryption happens before upload, the storage provider is untrusted by design: a compromised bucket leaks nothing readable.

2

Restoring one file, not the whole server

A configuration file overwritten this morning, a database dump deleted by a script. Browse yesterday's snapshot as a file tree in the browser, select the single file and restore it — no full restore, no downtime, no reading restic's manual under pressure.

3

Database dumps captured consistently

Use a pre-backup hook to run `mysqldump` or `pg_dump` into a directory, then let the plan snapshot it. You get an application-consistent backup rather than a copy of live database files, without writing your own cron chain.

4

Backups that tell you when they fail

The classic backup failure is silence — a job that stopped running three months ago and nobody noticed. Point the failure hook at your self-hosted ntfy topic and a broken backup pushes to your phone the same night, so you find out before the restore does.

Deploy Backrest on your VPS

Guide optimized for ServOrbit Cloud VPS.

01

Order a ServOrbit VPS

Any plan with 1 GB RAM is plenty — Backrest idles under 100 MB and the heavy lifting is I/O, not memory. Install it on the VPS you actually want to protect, since it backs up that machine's own filesystem.

02

Deploy Backrest from the ServOrbit marketplace

Open your ServOrbit dashboard → Marketplace → Backrest → Install. Provisioning pulls the image, mounts /home, /root and /etc read-only inside the container and starts it on port 9898. No domain name is required — the interface answers on the VPS IP.

03

Create your admin account

Open http://your-vps-ip:9898. On first run Backrest asks you to create a username and password — there are no default credentials. Do this immediately after install, before exposing the port beyond your own IP.

04

Add a repository

Add Repo, pick a backend and paste its credentials — for Backblaze B2 that is a bucket name plus an application key. Choose a strong repository password and store it in your password manager: restic encrypts with it, and without it the backups are unreadable, including by you.

05

Create a plan and schedule it

Add Plan, select the paths to protect (/host/home, /host/etc), set a cron schedule and a retention policy such as 7 daily, 4 weekly, 6 monthly. Run it once by hand to confirm it completes, then let the schedule take over — and add a failure hook so you hear about problems.

Frequently asked questions

restic is the backup engine — encrypted, deduplicated, incremental, and driven entirely from the command line. Backrest is a web UI and scheduler on top of it: the same engine and the same repository format, but repositories, plans, schedules, retention, restores and maintenance are managed in a browser instead of cron files and shell scripts. Your backups stay plain restic repositories, so you can always open them with the restic CLI — Backrest adds no lock-in.