Bist.be

Backing Up Self-Hosted Docker Services with Restic

bist

·

Self-hosting is great until you lose everything. A dead SD card, a botched upgrade, or a misconfigured volume mount can wipe out months of data in seconds. If you’re running services like Nextcloud, Immich, or Linkding on a Raspberry Pi or home server, you need a backup strategy that actually works.

I use Restic with a Hetzner Storage Box. Here’s how I set it up.

Why Restic?

There are plenty of backup tools out there. Restic stands out for a few reasons:

  • Deduplication — only changed data gets uploaded after the first backup
  • Encryption — data is encrypted before it leaves your machine
  • Multiple backends — works with local drives, SFTP, S3, Backblaze B2, and more
  • Fast restores — browse and restore individual files without downloading everything

It’s also simple. No daemons, no complex configuration files. Just a single binary and a few commands.

Why Hetzner Storage Box?

I wanted offsite backups but didn’t want to rely on big cloud providers. Hetzner Storage Box is cheap (€3.81/month for 1TB), based in Europe, and supports SFTP out of the box. Since Restic encrypts everything client-side, Hetzner only ever sees encrypted blobs.

There’s a certain irony in escaping Big Tech only to store backups on someone else’s server. But the encryption means I’m not trusting them with my data — just with storing opaque files. If Hetzner disappeared tomorrow, I’d lose access to my offsite backups but not my privacy.

My Setup

I run Docker services on a Raspberry Pi 4. Each application lives in its own directory:

/home/bist/
├── linkding/
│   ├── docker-compose.yml
│   └── data/
├── immich/
│   ├── docker-compose.yml
│   └── data/
└── nextcloud/
    ├── docker-compose.yml
    └── data/

Config and data together, per application. This makes backups straightforward — grab the whole folder and you have everything needed to restore that service.

Setting Up Restic with Hetzner

Install Restic

sudo apt install restic

Configure SSH Access

Hetzner Storage Box uses SFTP on port 23. First, upload your SSH key:

echo "mkdir .ssh" | sftp -P 23 uXXXXXX@uXXXXXX.your-storagebox.de
scp -P 23 ~/.ssh/id_rsa.pub uXXXXXX@uXXXXXX.your-storagebox.de:.ssh/authorized_keys

Test the connection:

sftp -P 23 uXXXXXX@uXXXXXX.your-storagebox.de

If it connects without a password prompt, you’re good.

Initialize the Repository

Create a directory for your backups and initialize Restic:

echo "mkdir backups" | sftp -P 23 uXXXXXX@uXXXXXX.your-storagebox.de

export RESTIC_REPOSITORY="sftp:uXXXXXX@uXXXXXX.your-storagebox.de:23:/backups"
export RESTIC_PASSWORD="your-strong-encryption-password"

restic init

Pick a strong password. Write it down somewhere safe — a password manager, a printed copy in a drawer, wherever. If you lose this password, your backups are gone. Restic has no recovery mechanism.

Create an Environment File

Rather than exporting variables every time, create a file:

~/.restic-env:

export RESTIC_REPOSITORY="sftp:uXXXXXX@uXXXXXX.your-storagebox.de:23:/backups"
export RESTIC_PASSWORD="your-strong-encryption-password"

Lock it down:

chmod 600 ~/.restic-env

Now you can just run source ~/.restic-env before any Restic command.

The Backup Script

I wrote a simple script that backs up each application directory:

#!/bin/bash

set -e

export RESTIC_REPOSITORY="sftp:uXXXXXX@uXXXXXX.your-storagebox.de:23:/backups"
export RESTIC_PASSWORD="your-strong-encryption-password"

BACKUP_DIRS=(
    "/home/bist/linkding"
    "/home/bist/immich"
    "/home/bist/nextcloud"
)

LOG_FILE="/home/bist/logs/restic-backup.log"
mkdir -p "$(dirname "$LOG_FILE")"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}

log "=== Starting backup ==="

for dir in "${BACKUP_DIRS[@]}"; do
    if [[ -d "$dir" ]]; then
        log "Backing up: $dir"
        restic backup "$dir" --exclude="*.log" --exclude="*.tmp"
    else
        log "Warning: $dir does not exist, skipping"
    fi
done

log "Pruning old snapshots..."
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

log "=== Backup complete ==="

restic snapshots --latest 3

Adding a new service means adding one line to the BACKUP_DIRS array.

The retention policy keeps the last 7 daily backups, 4 weekly, and 6 monthly. Old snapshots get pruned automatically, so storage doesn’t grow forever.

Automating with Cron

I run backups nightly at 3 AM:

crontab -e

0 3 * * * /home/bist/scripts/backup.sh

Logs go to /home/bist/logs/restic-backup.log so I can check what happened if something seems off.

Restoring

Backups are worthless if you can’t restore them. Here’s how.

List Snapshots

source ~/.restic-env
restic snapshots

This shows all your backups with timestamps and IDs.

Restore an Application

Always restore to a temporary location first:

restic restore latest --target /tmp/restore --include "/home/bist/linkding"

Check it looks right, then swap it into place:

cd /home/bist/linkding && docker compose down
mv /home/bist/linkding /home/bist/linkding.broken
mv /tmp/restore/home/bist/linkding /home/bist/
docker compose up -d

Once you’ve verified everything works, delete the broken copy.

Restore a Single File

restic restore latest --target /tmp/restore --include "/home/bist/linkding/docker-compose.yml"

Browse Backups Interactively

Restic can mount snapshots as a filesystem:

mkdir -p /tmp/restic-mount
restic mount /tmp/restic-mount

Browse with your file manager or terminal, copy what you need, then unmount.

The Most Important Step

Test your restores. A backup you’ve never tested is just a hope. Once a month or so, I pick a random service and restore it to /tmp just to make sure everything actually works.

What About Databases?

SQLite-based services (like Linkding) are fine — the database file gets backed up with everything else.

For services with MySQL or PostgreSQL, you should dump the database before the backup runs. For example, with Mailcow:

./helper-scripts/backup_and_restore.sh backup all

Then include the dump directory in your backup paths.

The 3-2-1 Rule

This setup gives me:

  • 3 copies: Live data + local snapshots + Hetzner
  • 2 media types: SD card + cloud storage
  • 1 offsite: Hetzner Storage Box

If my Pi dies, I buy a new one and restore from Hetzner. If Hetzner dies, I still have local data. If my house burns down… well, at least my bookmarks survive.

This post is part of a series on self-hosting and moving away from Big Tech services.

,