Restic ist mein Backup-Tool der Wahl. Ein Binary, keine Dependencies, Dutzende Cloud-Backends. Im ersten Artikel habe ich erklärt, warum ich zu Restic gewechselt bin. Hier geht es um die Praxis: Wie sieht ein echtes Backup-Skript aus, und wie stellt man Daten wieder her?
Das Backup-Skript
#!/bin/sh
if [ "x$1" = "x" ]
then
echo "usage: $0 <target>"
exit 1
fi
target=$1
. /backup/.secret.$target
set -e
echo -n "--- Starting restic backup at " && date
restic backup \
--exclude-caches \
--one-file-system \
--exclude-file /backup/exclude.txt \
--files-from /backup/toBackup.files
restic forget --group-by host --keep-daily 6 --keep-weekly 3 --keep-monthly 18
restic prune
curl -d "backup to $target successful" https://ntfy.frischux.de/backup > /dev/null 2>&1
echo -n "--- restic backup ended at " && date
exit 0
Zwei Zeilen, die alles steuern: Die Dateien, die gesichert werden sollen, und die Secrets für das Ziel. Der Rest ist Restic.
Was passiert im Detail
1. Ziel auswählen
Das Skript erwartet ein Argument – den Namen des Backup-Ziels:
./restic-backup.sh b2
Das Ziel wird dann in /backup/.secret.b2 ausgelesen. Dort stehen die Restic-Umgebungsvariablen:
# /backup/.secret.b2
export RESTIC_REPOSITORY=s3:backup.frischux.de:mein-repo
export RESTIC_PASSWORD_FILE=/backup/.restic-password
export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
So kann ich mit ein und demselben Skript auf verschiedene Ziele sichern (B2, lokale Platte, NAS) – nur das Argument ändert sich.
2. Was wird gesichert
restic backup \
--exclude-caches \
--one-file-system \
--exclude-file /backup/exclude.txt \
--files-from /backup/toBackup.files
| Parameter | Bedeutung |
|---|---|
--exclude-caches |
Überspringt Verzeichnisse mit CACHEDIR.TAG |
--one-file-system |
Bleibt auf dem aktuellen Dateisystem (kein Mount) |
--exclude-file |
Ausschlüsse aus Datei |
--files-from |
Nur die in der Datei gelisteten Pfade sichern |
Die Datei toBackup.files listet die Verzeichnisse auf:
/var/www/html
/var/lib/vaultwarden
/home/floyd
/etc
Die Datei exclude.txt schließt aus:
*.log
*.tmp
/home/floyd/.cache
/home/floyd/.local/share/Trash
3. Vergessen und Aufräumen
restic forget --group-by host --keep-daily 6 --keep-weekly 3 --keep-monthly 18
restic prune
Das ist die Retention-Policy:
| Alter | Behalten |
|---|---|
| Letzte 6 Tage | Jeder Tag |
| Letzte 3 Wochen | Jede Woche |
| Letzte 18 Monate | Jeder Monat |
--group-by host sorgt dafür, dass die Policy pro Host gilt – bei mehreren Servern wird jeder separat verwaltet. prune räumt dann die Snapshots auf, die nicht mehr behalten werden sollen.
4. Benachrichtigung
curl -d "backup to $target successful" https://ntfy.frischux.de/backup
Nach erfolgreichem Backup kommt eine Push-Nachricht aufs Handy. Bei Fehlern stoppt set -e das Skript vorher – die Nachricht kommt dann nicht, und ich weiß, dass etwas schiefgelaufen ist.
Restore – die verschiedenen Möglichkeiten
Restic bietet mehrere Wege, Daten wiederherzustellen. Je nach Situation ist ein anderer Ansatz sinnvoller.
Daten vollständig wiederherstellen: restic restore
# Letzten Snapshot wiederherstellen
restic restore latest --target /restore
# Bestimmten Snapshot
restic restore abc123 --target /restore
# Snapshot vom letzten Dienstag
restic restore "latest:2d" --target /restore
# Bestimmtes Verzeichnis aus einem Snapshot
restic restore latest --target /restore --include /var/www/html
Die Daten landen unter /restore/. Der Pfad wird relativ zum Root des Snapshots aufgebaut. Wer nur ein Verzeichnis braucht, spart sich das vollständige Restore.
Snapshot ansehen: restic snapshots
# Alle Snapshots auflisten
restic snapshots
# Snapshots nach Zeit filtern
restic snapshots --after 2026-06-01 --before 2026-07-01
# Snapshots nach Host filtern
restic snapshots --host server1
Die Ausgabe zeigt Snapshot-ID, Datum, Host und Datenmenge. Die ID wird für restore und mount benötigt.
Dateien durchsuchen: restic mount
# Snapshot als Dateisystem einhängen
restic mount --mountpoint /mnt/backup
# Bestimmten Snapshot einhängen
restic mount --mountpoint /mnt/backup --snapshot abc123
Danach sind alle Snapshots unter /mnt/backup/ als Dateien zugreifbar. Man kann durch die Verzeichnisse navigieren, Dateien anschauen, ohne etwas wiederherzustellen. Perfekt, um zu prüfen, ob ein bestimmtes File überhaupt im Backup ist.
# Beispiel: Letzte Version einer Datei anschauen
cat /mnt/backup/snapshots/latest/var/www/html/index.html
Differential-Backup: restic diff
# Unterschied zwischen zwei Snapshots anzeigen
restic diff abc123 def456
# Unterschied zum letzten Snapshot
restic diff abc123 latest
Zeigt an, welche Dateien geändert, hinzugefügt oder gelöscht wurden. Nützlich, um zu verstehen, was ein bestimmter Snapshot enthält.
Integrität prüfen: restic check
# Alle Datenblöcke prüfen
restic check
# Nur Snapshots prüfen (schneller)
restic check --read-data-subset=5%
Prüft, ob die im Repository gespeicherten Daten konsistent sind. Bei großen Repositories lohnt sich --read-data-subset, um die Prüfung schneller zu machen.
Restore-Szenarien
| Situation | Befehl |
|---|---|
| Kompletter Server-Verlust | restic restore latest --target / |
| Einzelnes Verzeichnis kaputt | restic restore latest --target / --include /var/www/html |
| Datei versehentlich gelöscht | restic mount + Kopieren |
| Prüfen, was im Backup ist | restic snapshots + restic mount |
| Daten auf neuen Server | restic restore latest --target /var |
Fazit
Restic ist das Tool, das ich jedem empfehle, der sichern will. Das Skript ist kurz, die Retention verständlich, und das Restore funktioniert auf mehrere Arten. Einfach restic backup und nachts schlafen.
Aber ein Backup ohne getestetes Restore ist nur eine Datei auf der Platte. Deshalb gehört das regelmäßige Üben des Restore dazu: Einmal im Monat einen Snapshot wiederherstellen, prüfen, ob die Daten stimmen, ob der Pfad stimmt, ob man den Befehl noch kennt. Im Ernstfall ist es dann kein Fremdeln mehr.
Wer seine Daten ernst nimmt, sollte Restic mal ausprobieren. Die Einarbeitungszeit beträgt eine Stunde, danach hat man ein Backup-System, das zuverlässig läuft und einem nicht auf die Nerven geht.
