Restic: verschlüsselte Sicherungen, die man auch zurückspielt

Für Dateien auf einem VPS ist Restic eine gute Antwort: ein einzelnes Programm, verschlüsselt von sich aus, spricht mit lokalen Verzeichnissen, SFTP, S3-kompatiblem Speicher und einigen anderen Zielen. Was daran schiefgeht, hat selten mit Restic zu tun und viel mit dem Schlüssel und dem Rückweg.

Repository anlegen#

apt install restic
restic version

Das Ziel ist ein Repository: ein Verzeichnis, das Restic selbst verwaltet. Sein Passwort ist der Schlüssel zu allem, was darin liegt.

# Beispiel: S3-kompatibler Speicher
export RESTIC_REPOSITORY="s3:https://s3.example.com/mein-bucket"
export AWS_ACCESS_KEY_ID="…"
export AWS_SECRET_ACCESS_KEY="…"
export RESTIC_PASSWORD_FILE=/root/.restic-pass

install -m 600 /dev/null /root/.restic-pass
head -c 32 /dev/urandom | base64 > /root/.restic-pass    # ein echtes Zufallspasswort
restic init

Sichern#

restic backup /etc /srv /home \
  --exclude-caches \
  --exclude='/srv/*/cache' \
  --tag taeglich

--exclude-caches überspringt Verzeichnisse mit CACHEDIR.TAG, das spart bei vielen Anwendungen deutlich Platz, ohne dass man Ausschlusslisten pflegt.

Datenbanken werden nicht einfach mitkopiert. Erst ein konsistenter Auszug, dann sichern, die Verfahren stehen in Datenbank sichern und wirklich zurückspielen:

sudo -u postgres pg_dump -Fc meineapp > /var/backups/meineapp.dump
restic backup /var/backups /etc /srv --tag taeglich

Wer den Zwischenschritt auf der Platte sparen will, schickt den Auszug direkt hinein:

sudo -u postgres pg_dump -Fc meineapp | restic backup --stdin --stdin-filename meineapp.dump

Als Timer, nicht als Cronjob#

# /etc/systemd/system/restic.service
[Service]
Type=oneshot
EnvironmentFile=/etc/restic.env
ExecStart=/usr/bin/restic backup /etc /srv /home --exclude-caches --tag taeglich
ExecStartPost=/usr/bin/restic forget --prune \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 12
Nice=10
IOSchedulingClass=idle

# /etc/systemd/system/restic.timer
[Timer]
OnCalendar=*-*-* 02:30
RandomizedDelaySec=20m
Persistent=true

[Install]
WantedBy=timers.target

systemctl enable --now restic.timer
systemctl list-timers restic.timer
journalctl -u restic.service -n 50

Persistent=true holt einen Lauf nach, der ausgefallen ist, weil die Maschine aus war. RandomizedDelaySec verteilt die Last, wenn mehrere Server dasselbe Ziel beschreiben. Warum Timer und nicht Cron: systemd-Timer statt Cronjob.

Aufräumen und die Falle dabei#

forget markiert alte Sicherungspunkte, prune gibt den Platz tatsächlich frei. Zusammen sind sie der langsamste Teil des Laufs, weil das Repository umgeschrieben wird.

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --dry-run

restic list locks
ps aux | grep restic          # läuft noch etwas?
restic unlock                 # erst danach

Prüfen, dass die Sicherung etwas taugt#

Drei Stufen, von billig nach gründlich:

# 1. Struktur prüfen (schnell)
restic check

# 2. Stichprobe: 5 % der Daten wirklich lesen und entschlüsseln
restic check --read-data-subset=5%

# 3. Der einzige echte Test: zurückspielen
restic restore latest --target /tmp/probe --include /etc/nginx
diff -r /etc/nginx /tmp/probe/etc/nginx && echo "identisch"

Stufe 3 gehört in den Kalender, nicht in den guten Vorsatz. Einmal im Quartal, mit Datum notiert, dieselbe Regel wie in 3-2-1.

Praktisch für den Alltag ist außerdem das Einhängen des Repositorys als Dateisystem:

mkdir /mnt/restic && restic mount /mnt/restic
# in einem zweiten Terminal:
ls /mnt/restic/snapshots/latest/etc/

Überwachen#

Eine Sicherung, die seit drei Wochen scheitert, ist schlimmer als keine, weil man sich auf sie verlässt.

# Wie alt ist die letzte Sicherung?
restic snapshots --latest 1 --json | jq -r '.[0].time'

Der Wert gehört in die vorhandene Überwachung (Monitoring aufsetzen), mit Alarm ab 36 Stunden ohne Erfolg. Ein Dead-Man-Switch ist hier besser als eine Fehlermeldung: Er schlägt auch an, wenn der Server komplett aus ist.

Häufige Fragen#

Restic oder Borg?#

Beide taugen. Restic spricht mehr Ziele direkt an (S3, Backblaze, REST) und ist ein einzelnes Programm ohne Server-Gegenstück. Borg ist bei Deduplizierung über sehr viele ähnliche Systeme oft sparsamer. Wer keins von beiden hat, nimmt Restic.

Wie groß wird das Repository?#

Restic dedupliziert auf Blockebene: Der erste Lauf kostet die volle Datenmenge, danach wächst es mit den Änderungen. Wie viel das ist, sagt dir dein eigener Lauf, restic stats nach zwei Wochen ist aussagekräftiger als jede Faustformel.

Kann ich damit die ganze VM sichern?#

Kannst du, willst du meistens nicht. Für virtuelle Maschinen ist die Ebene darunter richtig (Proxmox Backup Server); Restic sichert die Daten im Gast. Beides zusammen ist die übliche Aufteilung.

Was, wenn der Speicheranbieter wegfällt?#

Deshalb zwei Ziele. Restic kann dasselbe Quellverzeichnis in zwei Repositories sichern, zwei Timer, zwei Umgebungsdateien, fertig.

Ist die Verschlüsselung abschaltbar?#

Nein, und das ist gut so. Das Repository ist immer verschlüsselt; genau deshalb darf es auf fremdem Speicher liegen.

Kurz gesagt#

• Das Repository-Passwort liegt zusätzlich woanders, sonst ist die Sicherung Zierde.
• Datenbanken erst dumpen, dann sichern.
• systemd-Timer mit Persistent=true, prune seltener und getrennt.
• restic check --read-data-subset regelmäßig, Rückspielen quartalsweise üben.
• Alter der letzten Sicherung überwachen, nicht nur den Fehlerfall.