restic REST-Server as a Central Backup Target

In many small and mid-sized businesses, backups are a patchwork: a NAS protects the file servers, a cloud product handles the laptops, a script copies the database somewhere. Anyone who takes consistency and recoverability seriously needs a single, unified backup target. The restic REST-Server is built exactly for that purpose — a lightweight Go daemon that exposes restic repositories over HTTPS. Combined with per-user authentication and append-only mode, it becomes a ransomware-resistant backup platform that runs on any Linux server.

This article shows how to set up the restic REST-Server (version 0.13.x, as of 2026) in TLS mode, cleanly separate multiple clients, plan storage realistically and get key management under control.

Architecture: One Host, Many Repositories

The REST-Server is a single process that serves one repository per path. In multi-user mode (--private-repos), each authenticated client reads and writes only to its own directory — the path is derived from the user name:

/srv/restic/
├── srv-mail/        # mail server repository
├── srv-db/          # database server repository
├── nb-mueller/      # laptop Mueller repository
└── nb-schmidt/      # laptop Schmidt repository

Laptops, servers and VMs all end up on the same machine — but each client sees only its own data. This avoids cross-contamination and keeps permissioning simple. A compromised laptop account can neither delete nor read the server backups.

A practical recommendation: for a manageable SMB environment with up to 50 clients, one repository per host is fine. For larger setups or strict tenant separation, one repository per organisational unit is the better choice — deduplication then only works within that unit, but separation is cleaner and restores are faster.

Installation and Systemd Service

The REST-Server ships as a static binary. We create a dedicated system user and install the binary to /usr/local/bin:

# Create user and data directory
useradd --system --home /srv/restic --shell /usr/sbin/nologin restic
install -d -o restic -g restic -m 0750 /srv/restic

# Fetch the binary (version 0.13.0 - 2026)
curl -L https://github.com/restic/rest-server/releases/download/v0.13.0/\
rest-server_0.13.0_linux_amd64.tar.gz | tar -xz -C /tmp
install -m 0755 /tmp/rest-server_0.13.0_linux_amd64/rest-server /usr/local/bin/

# Htpasswd for authentication
apt install -y apache2-utils
htpasswd -B -c /srv/restic/.htpasswd srv-mail
htpasswd -B    /srv/restic/.htpasswd srv-db
htpasswd -B    /srv/restic/.htpasswd nb-mueller
chown restic:restic /srv/restic/.htpasswd
chmod 0640         /srv/restic/.htpasswd

The systemd unit /etc/systemd/system/rest-server.service:

[Unit]
Description=restic REST Server
After=network.target

[Service]
User=restic
Group=restic
ExecStart=/usr/local/bin/rest-server \
  --path /srv/restic \
  --listen 0.0.0.0:8443 \
  --htpasswd-file /srv/restic/.htpasswd \
  --private-repos \
  --append-only \
  --tls \
  --tls-cert /etc/restic/fullchain.pem \
  --tls-key  /etc/restic/privkey.pem
Restart=on-failure
ProtectSystem=strict
ReadWritePaths=/srv/restic
NoNewPrivileges=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

With systemctl enable --now rest-server the service is running. The TLS certificates can come from Let’s Encrypt via DNS-01 challenge — renewal should restart rest-server through a --deploy-hook.

Append-Only: The Decisive Protection Against Ransomware

The single most important flag in the configuration is --append-only. It allows every client to create new snapshots, but never to delete or overwrite existing data. Even if a laptop gets infected with ransomware and the attacker finds the restic key — the backups on the REST-Server remain untouched.

Concretely, the server blocks the HTTP DELETE method and refuses to overwrite existing objects. A restic forget --prune will fail. That has a consequence: pruning has to happen from a different context.

The clean solution: a separate cron job on the REST-Server host itself that applies the retention policies periodically using direct filesystem access (bypassing the HTTP layer). This way the attacker on the client never has the ability to destroy the backup — only the well-secured backup host can do that.

# /etc/cron.weekly/restic-prune (runs as root on the backup host)
#!/usr/bin/env bash
set -euo pipefail
for repo in /srv/restic/*/; do
  pw=$(cat "${repo}.password")
  RESTIC_PASSWORD="$pw" restic -r "$repo" forget \
    --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune
done

Storage Planning and Deduplication

restic deduplicates on the block level using content-defined chunking. That makes capacity planning very different from classical full/incremental concepts. A realistic picture from production SMB setups:

Workload	Raw data	Repository	Dedup ratio	Daily growth
Office laptops (mixed)	250 GB	180 GB	1.4 : 1	0.3 — 0.8 GB
File server with Office documents	2 TB	1.1 TB	1.8 : 1	3 — 8 GB
PostgreSQL dump (compressed)	80 GB	70 GB	1.1 : 1	2 — 4 GB
VM images (qcow2, shared base)	600 GB	95 GB	6.3 : 1	0.5 — 2 GB
Mail server (Maildir)	400 GB	310 GB	1.3 : 1	1 — 3 GB

Rule of thumb: for 12 months retention on typical office workloads, plan for 1.2 - 1.8 times the raw data volume. VM images with a shared base benefit disproportionately from deduplication — ratios of 5:1 and more are realistic here. Database dumps and already compressed archives barely deduplicate; linear growth dominates.

If you put the volume under the REST-Server on ZFS — for example on a small TrueNAS instance or a Linux host with ZFS on Linux — you get additional snapshots, scrubs and checksums for free. ZFS compression (lz4 or zstd) typically adds another 5 - 10 percent on restic repositories, because the chunks are already relatively incompressible.

Key Management: Who Knows Which Password?

Every restic repository has its own password protecting the symmetric encryption (AES-256). Lose the password and the data is gone — restic is a zero-knowledge system from the server operator’s perspective. That is good for confidentiality but operationally demanding.

Battle-tested approach:

1. One password per client. Never the same password across multiple repositories.
2. Add a master key as well. With restic key add you can store a second key per repository, kept centrally in the admin team’s password manager. Recovery remains possible even if the client key is lost.
3. Back up keys offline. Master keys belong — printed or on an encrypted USB stick — in the safe. Skimping here means encrypted backups but no way to access them in an emergency.
4. Document rotation. Use restic key passwd to change the client password without re-encrypting the repository. Document rotations in the internal wiki.

On the client side it is best not to embed the password in scripts but to read it via RESTIC_PASSWORD_FILE from a file with 0400 permissions readable only by root. On laptops, the system keychain (libsecret, Keychain) is the right choice.

Client Configuration and Monitoring

A typical client backup job looks like this:

export RESTIC_REPOSITORY="rest:https://srv-mail:passwd@backup.example.com:8443/"
export RESTIC_PASSWORD_FILE="/etc/restic/repo-password"

restic backup \
  --tag daily \
  --exclude-caches \
  --exclude /var/cache \
  --exclude /tmp \
  / /home /var

# Integrity check (once per week)
restic check --read-data-subset=10%

The restic check --read-data-subset call matters — it actually reads data and verifies hashes. A backup that has never been restored or verified is not a backup. If running full restore tests regularly feels too costly, at least let restic check a percentage of the repository every week.

For monitoring, exit codes plus logfile evaluation work well. With DATAZONE Control you integrate the jobs as custom checks and get a central view of all backup endpoints — including alerts when a laptop has missed three days of backups in a row.

Off-Site Replication of the REST-Server

The REST-Server is only the first 3-2-1 layer. A second repository at another site is most easily populated with restic copy — it only transfers chunks not already present at the target and is therefore bandwidth-friendly. Alternatively, replicate the entire data directory using rsync or ZFS send/receive to a disaster recovery datacenter.

In SMB environments without a second physical site, S3-compatible object storage (Wasabi, Backblaze B2, Hetzner) is a good option for the off-site copy — restic can write there directly, or restic copy can replicate from the REST-Server repository.

Conclusion

The restic REST-Server is one of the underrated tools in the open-source backup space. Set up in a few hours, running on commodity hardware, reliably ransomware-resistant thanks to append-only and scaling surprisingly far thanks to deduplication. For many SMBs, it is the right answer between “let’s just buy Veeam” and “we don’t need anything”.

DATAZONE supports you with planning, building and operating restic-based backup infrastructures — from hardware sizing through hardening the Linux host and designing your backup strategy to monitoring with DATAZONE Control. Get in touch if you want to consolidate your backup landscape and harden it against ransomware.