Backups mit restic: verschlüsselt auf S3 und Spaces

Wer selbst hostet, hat irgendwann einen Server voller Daten, die es nirgendwo sonst gibt: die Fotos in Immich, die gescannten Dokumente in Paperless, den Passwort-Tresor in Vaultwarden. Fällt die Festplatte aus, löscht ein Update das falsche Volume oder verschlüsselt ein Angreifer den Server, ist ohne Backup alles weg. Ein Snapshot beim Hoster hilft dabei nur bedingt, denn er liegt beim selben Anbieter und lässt sich meist nur komplett zurückspielen.

restic ist das Werkzeug, mit dem Du das sauber löst. Es verschlüsselt alles, bevor es Deinen Rechner verlässt, speichert jede Datei nur einmal, auch wenn sie in hundert Sicherungen vorkommt, und überträgt nach der ersten Sicherung nur noch Änderungen. Ziel kann ein S3-Speicher, ein NAS oder eine externe Platte sein. Ein Programm, eine Befehlssyntax, für Linux-Server und Mac gleichermaßen.

Diese Anleitung sichert einen Linux-Server und einen Mac in einen S3-Bucket bei DigitalOcean Spaces, automatisiert die Sicherung und zeigt, wie Du Dateien wiederherstellst. Stand ist restic 0.19.1 vom Juli 2026. Die Befehle folgen der offiziellen restic-Dokumentation.

Warum restic und wohin damit

Es gibt mehrere gute Backup-Programme für Linux, etwa Borg oder Kopia. restic hat für Selfhoster einen entscheidenden Vorteil: Es spricht S3 direkt und braucht auf der Gegenseite keine Software. Borg braucht auf dem Ziel einen SSH-Zugang mit installiertem Borg, Kopia bringt eine eigene Server-Komponente mit. restic schreibt einfach verschlüsselte Blöcke in einen Bucket.

Als Ziel nimmt diese Anleitung DigitalOcean Spaces, den S3-kompatiblen Speicher von DigitalOcean. Laut der Preisübersicht von DigitalOcean kostet er 5 US-Dollar im Monat, inklusive 250 GiB Speicher und 1.024 GiB ausgehendem Datenverkehr. Das reicht für die meisten Heimserver locker. Liegt Dein Server selbst bei DigitalOcean, wähle für die Sicherung trotzdem eine andere Region, damit ein Ausfall eines Rechenzentrums nicht Server und Backup gleichzeitig trifft. Wenn Du noch kein Konto hast, bekommst Du über diesen Link zu DigitalOcean (Affiliate Link) Startguthaben zum Ausprobieren.

Jeder andere S3-Anbieter funktioniert genauso, Du änderst nur die Adresse.

Bucket und Zugangsschlüssel anlegen

1. Lege im DigitalOcean-Kontrollzentrum unter Spaces Object Storage einen neuen Bucket an, zum Beispiel in der Region Amsterdam (AMS3) mit dem Namen mein-backup. Der Name muss bei DigitalOcean weltweit eindeutig sein, häng also notfalls ein Kürzel an.
2. Lege danach einen Zugangsschlüssel an. Wähle dabei Limited Access und gib dem Schlüssel Lese- und Schreibrechte nur für diesen einen Bucket. So kann ein kompromittierter Server nicht auf Deine anderen Buckets zugreifen.
3. Notiere Dir Access Key und Secret Key. Der Secret Key wird nur einmal angezeigt.

restic installieren

Auf einem Server mit Debian oder Ubuntu installierst Du restic aus den Paketquellen:

sudo apt update
sudo apt install restic

Auf dem Mac nimmst Du Homebrew:

brew install restic

Prüfe danach mit restic version, ob es funktioniert. Die Version aus den Debian-Paketquellen ist manchmal etwas älter als die aktuelle. Für die Befehle in dieser Anleitung spielt das keine Rolle.

Zugangsdaten und Passwort hinterlegen

restic liest die Zugangsdaten aus Umgebungsvariablen. Damit sie nicht in jedem Befehl stehen, legst Du sie auf dem Server in einer Datei ab, die nur root lesen kann. Erstelle zuerst das Passwort für die Verschlüsselung:

sudo sh -c 'openssl rand -base64 32 > /root/.restic-passwort'
sudo chmod 600 /root/.restic-passwort

Der erste Befehl erzeugt ein zufälliges Passwort mit 32 Byte und schreibt es in die Datei, der zweite sorgt dafür, dass nur root sie lesen kann. Kopiere dieses Passwort sofort in Deinen Passwortmanager. Ohne es lassen sich die Sicherungen nicht mehr entschlüsseln, auch nicht von Dir. Ein Backup, dessen Passwort nur auf dem gesicherten Server liegt, ist bei einem Totalausfall wertlos.

Dann legst Du die Datei mit den Zugangsdaten an:

sudo nano /root/.restic-env

Füge diese vier Zeilen ein und ersetze die Platzhalter durch Deine Werte:

export AWS_ACCESS_KEY_ID=DEIN_ACCESS_KEY
export AWS_SECRET_ACCESS_KEY=DEIN_SECRET_KEY
export RESTIC_REPOSITORY=s3:https://ams3.digitaloceanspaces.com/mein-backup/server
export RESTIC_PASSWORD_FILE=/root/.restic-passwort

Die Adresse in RESTIC_REPOSITORY setzt sich aus der Region, dem Bucket-Namen und einem Unterordner zusammen. Der Unterordner server erlaubt Dir, später den Mac in denselben Bucket unter mac zu sichern. Speichere mit Strg + O, bestätige mit Enter und schließe den Editor mit Strg + X. Schütze auch diese Datei:

sudo chmod 600 /root/.restic-env

Das Repository anlegen und die erste Sicherung

Wechsle für die nächsten Schritte in eine root-Shell und lade die Zugangsdaten:

sudo -i
source /root/.restic-env

Lege dann das Repository an:

restic init

restic legt im Bucket die Struktur an und meldet created restic repository. Jetzt folgt die erste Sicherung. Bei einem typischen Docker-Server liegen die Daten unter /opt oder in den Docker-Volumes unter /var/lib/docker/volumes. Passe die Pfade an Deinen Server an:

restic backup /opt /etc /var/lib/docker/volumes --exclude-caches

Die erste Sicherung überträgt alles und dauert je nach Datenmenge und Upload eine Weile. Jede weitere ist deutlich schneller, weil restic nur geänderte Blöcke hochlädt. Am Ende zeigt restic, wie viele Dateien es verarbeitet und wie viel es tatsächlich hochgeladen hat. Mit diesem Befehl listest Du die vorhandenen Sicherungen auf:

restic snapshots

Datenbanken richtig sichern

Hier liegt der häufigste Fehler bei Server-Backups. Eine Datenbank wie PostgreSQL oder MariaDB schreibt ständig in ihre Dateien. Kopierst Du diese Dateien im laufenden Betrieb, erhältst Du womöglich einen Zustand, mit dem die Datenbank später nicht mehr startet.

Die Lösung ist ein Export der Datenbank vor jeder Sicherung. Für einen PostgreSQL-Container wie bei Immich sieht das so aus:

mkdir -p /opt/db-dumps
docker exec immich_postgres pg_dumpall --clean --if-exists --username=postgres | gzip > /opt/db-dumps/immich.sql.gz

Der Befehl lässt pg_dumpall im laufenden Container einen konsistenten Export erzeugen und schreibt ihn komprimiert nach /opt/db-dumps. Den Ordner sichert restic dann wie jeden anderen. Den Namen des Containers zeigt Dir docker ps. Für MariaDB und MySQL nimmst Du entsprechend mariadb-dump oder mysqldump.

Alte Sicherungen aufräumen

Ohne Aufräumen wächst das Repository endlos. Mit forget legst Du fest, welche Sicherungen bleiben, und --prune löscht die nicht mehr benötigten Daten:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Damit bleiben die Sicherungen der letzten sieben Tage, je eine pro Woche für vier Wochen und je eine pro Monat für ein Jahr. Das ist ein guter Ausgangspunkt für einen Heimserver.

Alles automatisch: das Backup-Skript

Fass die Schritte in einem Skript zusammen:

sudo nano /usr/local/bin/backup.sh

#!/bin/bash
set -euo pipefail
source /root/.restic-env

mkdir -p /opt/db-dumps
docker exec immich_postgres pg_dumpall --clean --if-exists --username=postgres | gzip > /opt/db-dumps/immich.sql.gz

restic backup /opt /etc /var/lib/docker/volumes --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
restic check

set -euo pipefail bricht das Skript beim ersten Fehler ab, damit ein gescheiterter Datenbank-Export nicht unbemerkt bleibt. restic check prüft am Ende, ob die Struktur des Repositorys in Ordnung ist. Mach das Skript ausführbar:

sudo chmod 700 /usr/local/bin/backup.sh

Starte es einmal von Hand mit sudo /usr/local/bin/backup.sh und prüfe, ob es ohne Fehler durchläuft. Danach trägst Du es in die Crontab von root ein:

sudo crontab -e

30 3 * * * /usr/local/bin/backup.sh >> /var/log/restic-backup.log 2>&1

Die Sicherung läuft dann jede Nacht um 3:30 Uhr, und die Ausgabe landet im Log. Wie die Zeitangaben in der Crontab aufgebaut sind, erklärt die Anleitung: Cronjobs unter Raspberry Pi OS einrichten, die auf jedem Debian-System genauso funktioniert.

Ein Backup, das seit Wochen still fehlschlägt, ist der zweithäufigste Fehler. Lass Dich deshalb bei Fehlern benachrichtigen. Wie Du dafür einen eigenen Push-Dienst betreibst, zeigt die Anleitung Push-Benachrichtigungen selbst hosten mit ntfy.

Den Mac mit sichern

Auf dem Mac legst Du die Zugangsdaten genauso an, nur in Deinem Benutzerordner, etwa in ~/.restic-env, und mit dem Unterordner mac in der Adresse:

export RESTIC_REPOSITORY=s3:https://ams3.digitaloceanspaces.com/mein-backup/mac

Nach restic init sicherst Du Deine wichtigsten Ordner:

restic backup ~/Documents ~/Desktop ~/Pictures --exclude-caches

Damit restic auf geschützte Ordner zugreifen darf, braucht das Terminal unter Systemeinstellungen > Datenschutz & Sicherheit > Festplattenvollzugriff die Freigabe. Für die automatische Sicherung nimmst Du am Mac besser launchd statt cron, weil der Mac nachts oft schläft. Wie das geht, zeigt die Anleitung Hintergrund-Jobs am Mac mit launchd statt cron. Ein restic-Backup ersetzt Time Machine nicht, sondern ergänzt es um eine Kopie außer Haus.

Wiederherstellen: der Test, auf den es ankommt

Ein Backup ist erst dann eines, wenn Du daraus wiederherstellen kannst. Probiere es aus, solange nichts kaputt ist. Mit diesem Befehl siehst Du, welche Dateien in der neuesten Sicherung liegen:

restic ls latest /etc

Eine einzelne Datei oder einen Ordner holst Du so in ein Testverzeichnis zurück:

restic restore latest --target /tmp/wiederherstellung --include /etc/hostname

restic legt die Datei mit vollem Pfad unter /tmp/wiederherstellung/etc/hostname ab. Vergleiche den Inhalt mit dem Original. Für eine komplette Wiederherstellung auf einem neuen Server installierst Du restic, legst dieselbe .restic-env mit demselben Passwort an und lässt restic restore latest --target / laufen.

Einmal im Monat lohnt sich außerdem eine gründlichere Prüfung, bei der restic einen Teil der Daten tatsächlich herunterlädt und entschlüsselt:

restic check --read-data-subset=5%

Häufige Fehlermeldungen

Fatal: unable to open config file beim Backup. Das Repository wurde noch nicht angelegt, oder die Adresse in RESTIC_REPOSITORY stimmt nicht. Prüfe Region und Bucket-Namen und führe restic init aus.

Access Denied beim Anlegen. Der Zugangsschlüssel hat keine Schreibrechte auf den Bucket. Prüfe bei DigitalOcean, für welchen Bucket der Schlüssel freigegeben ist.

repository is already locked. Ein vorheriger Lauf wurde abgebrochen und hat eine Sperre hinterlassen. Prüfe, dass kein restic mehr läuft, und entferne die Sperre mit restic unlock.

Das Wichtigste zum Schluss

Mit einem Skript von zehn Zeilen und einem Cronjob sicherst Du Deinen Server verschlüsselt außer Haus, für 5 US-Dollar im Monat. Der Aufwand liegt bei einer Stunde, und das Wichtigste dabei sind nicht die Befehle, sondern zwei Gewohnheiten: Das Passwort liegt zusätzlich im Passwortmanager, und Du probierst die Wiederherstellung aus, bevor Du sie brauchst.