Backups mit restic

Modul 8: Backups und Überwachung · Lesezeit: 12 Minuten

Lernziel: Nach dieser Lektion können Sie mit restic verschlüsselte Backups auf Speicher außerhalb Ihres Servers anlegen, alte Versionen nach einem Aufbewahrungsschema aufräumen, das Backup prüfen und Dateien wiederherstellen und das Ganze automatisch laufen lassen.

Kernbegriffe: restic, Repository, init, Passwort(datei), Backend (sftp, S3, rest-server), backup, snapshots, forget, --keep-daily/--keep-weekly/--keep-monthly, prune, check, restore, mount, Deduplizierung, append-only, systemd-Timer

Warum restic?

Es gibt viele Backup-Programme. restic ist eine gute Wahl für einen eigenen Server, weil es:

• alles verschlüsselt, bevor es den Server verlässt; der Speicher sieht nur unlesbare Blöcke;
• dedupliziert: Eine Datei, die sich nicht geändert hat, wird nicht erneut gespeichert, daher kosten tägliche Backups wenig Platz;
• viele Arten von Speicher kennt: ein Verzeichnis, einen anderen Server per SFTP, S3-kompatiblen Speicher, einen eigenen rest-server;
• ein einzelnes Programm ist, das in den Paketquellen von Debian und Ubuntu enthalten ist (apt install restic).

Eine Alternative mit ähnlichen Eigenschaften ist BorgBackup. Die Prinzipien aus dieser Lektion gelten dort ebenso.

Die Begriffe

• Repository: der Ort, an dem restic die Backups speichert. Immer außerhalb des Servers, den Sie sichern.
• Snapshot: ein Backup zu einem Zeitpunkt. (Achtung: Das ist etwas anderes als der Snapshot Ihres Anbieters aus Lektion 8.1.)
• Passwort: Jedes Repository hat ein Passwort, mit dem alles verschlüsselt wird. Die Dokumentation von restic ist da eindeutig: Wer das Passwort verliert, verliert die Daten unwiderruflich.

Ein Repository anlegen

Angenommen, Sie haben einen Speicherserver backup.example.net, auf den Sie per SFTP mit einem Schlüssel zugreifen können, als Benutzer web1. Legen Sie zuerst eine Passwortdatei auf dem Server an (und bewahren Sie dasselbe Passwort in Ihrem Passwortmanager auf, Lektion 8.1):

root@web1:~# install -m 600 /dev/null /root/.restic-wachtwoord
root@web1:~# openssl rand -base64 32 > /root/.restic-wachtwoord
root@web1:~# export RESTIC_REPOSITORY=sftp:web1@backup.example.net:/srv/restic/web1
root@web1:~# export RESTIC_PASSWORD_FILE=/root/.restic-wachtwoord
root@web1:~# restic init
created restic repository 5f1a9c2e3b at sftp:web1@backup.example.net:/srv/restic/web1

Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

Mit den Umgebungsvariablen RESTIC_REPOSITORY und RESTIC_PASSWORD_FILE müssen Sie die Optionen -r und --password-file nicht jedes Mal eingeben.

Ein Backup erstellen

Zuerst der Datenbank-Dump (Lektion 8.1), dann das Backup:

root@web1:~# restic backup /etc /var/www /opt /var/backups/db \
    --exclude /var/www/*/cache --tag dagelijks
repository 5f1a9c2e opened (version 2, compression level auto)
...
Files:        8421 new,     0 changed,     0 unmodified
Dirs:         1203 new,     0 changed,     0 unmodified
Added to the repository: 612.338 MiB (402.117 MiB stored)

processed 8421 files, 1.204 GiB in 0:41
snapshot 3c7e91d4 saved

Am nächsten Tag geht es viel schneller: Nur was sich geändert hat, wird übertragen.

root@web1:~# restic snapshots
ID        Time                 Host  Tags       Paths
-----------------------------------------------------------------------
3c7e91d4  2026-11-08 03:10:02  web1  dagelijks  /etc /opt /var/backups/db /var/www
a18f0b77  2026-11-09 03:10:05  web1  dagelijks  /etc /opt /var/backups/db /var/www
-----------------------------------------------------------------------
2 snapshots

Aufräumen: forget und prune

Jeden Tag ein Snapshot mehr bedeutet nach einem Jahr 365 Snapshots. Mit forget legen Sie über ein Aufbewahrungsschema fest, welche Sie behalten:

root@web1:~# restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

So funktioniert das Schema:

• --keep-daily 7: Betrachte die letzten sieben Tage, an denen es einen Snapshot gibt, und behalte pro Tag den neuesten;
• --keep-weekly 4: ebenso für die letzten vier Wochen (Montag bis einschließlich Sonntag);
• --keep-monthly 6: ebenso für die letzten sechs Monate.

Ein Snapshot bleibt erhalten, wenn er mindestens eine der Regeln erfüllt. Alles, was keine einzige Regel erfüllt, wird vergessen. Testen Sie ein neues Schema zuerst mit --dry-run: Dann sehen Sie, was entfernt würde, ohne dass sich etwas ändert.

Wichtiger Unterschied: forget entfernt nur den Verweis auf einen Snapshot. Die Daten bleiben im Repository, bis prune die Blöcke aufräumt, die von keinem Snapshot mehr verwendet werden. Die Option --prune bei forget erledigt das in einem Schritt. Prune kostet Zeit und sperrt das Repository; planen Sie es deshalb nicht gleichzeitig mit Ihrem Backup.

Prüfen: check

Ein Backup, das unbemerkt beschädigt wird, fällt Ihnen erst bei der Wiederherstellung auf. Lassen Sie restic das Repository regelmäßig prüfen:

root@web1:~# restic check
...
no errors were found
root@web1:~# restic check --read-data-subset=5%

Ein einfaches check prüft die Struktur. Mit --read-data-subset liest restic zusätzlich einen Teil der Daten tatsächlich zurück und prüft den Inhalt. Machen Sie das zum Beispiel wöchentlich mit ein paar Prozent; so ist nach einiger Zeit alles einmal gelesen worden.

Wiederherstellen: restore und mount

Stellen Sie in ein separates Verzeichnis wieder her, niemals direkt über das Original:

root@web1:~# restic restore latest --target /tmp/terug --include /etc/nginx
restoring snapshot a18f0b77 of [/etc /opt /var/backups/db /var/www] at 2026-11-09 03:10:05 ...
Summary: Restored 41 files/dirs (88.104 KiB) in 0:00
root@web1:~# diff -r /tmp/terug/etc/nginx /etc/nginx && echo gelijk
gelijk

latest ist der neueste Snapshot; Sie können auch eine ID verwenden (restic restore 3c7e91d4 ...). Mit restic mount /mnt/restic (erfordert FUSE) sehen Sie alle Snapshots als Verzeichnisse und können sich umsehen und einzelne Dateien kopieren. Beenden mit Strg+C.

Eine Datenbank stellen Sie wieder her, indem Sie den Dump zurückholen und importieren, zum Beispiel gunzip < alles.sql.gz | mariadb.

Automatisch, jede Nacht

Erstellen Sie ein Skript und einen systemd-Timer (Lektion 6.3). Das Skript:

#!/bin/sh
# /usr/local/sbin/backup.sh
set -eu
export RESTIC_REPOSITORY=sftp:web1@backup.example.net:/srv/restic/web1
export RESTIC_PASSWORD_FILE=/root/.restic-wachtwoord
mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alles.sql.gz
restic backup /etc /var/www /opt /var/backups/db --tag dagelijks
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Dazu eine .service mit Type=oneshot und ExecStart=/usr/local/sbin/backup.sh sowie eine .timer mit OnCalendar=*-*-* 03:10:00 und Persistent=true. set -eu sorgt dafür, dass das Skript beim ersten Fehler abbricht, sodass systemd den Lauf als fehlgeschlagen erkennt. Verknüpfen Sie eine Benachrichtigung damit (Lektion 8.3), sonst bemerken Sie ein fehlgeschlagenes Backup nicht.

Gegen Ransomware: append-only

Im obigen Skript kann der Server das Backup auch selbst löschen (forget und prune). Übernimmt ein Angreifer den Server, kann er das also ebenfalls. Zwei Wege, das zu verhindern:

• rest-server im append-only-Modus: Auf dem Speicherserver betreiben Sie den eigenen rest-server von restic mit der Option --append-only. Der Webserver kann dann zwar Backups hinzufügen, aber nichts löschen. Das Aufräumen (forget --prune) erledigen Sie von einem anderen, gut abgesicherten Rechner mit vollen Rechten.
• Speicher mit Versionierung oder Objektsperre bei einem S3-Anbieter, sodass gelöschte Objekte noch eine Zeit lang wiederhergestellt werden können.

Achten Sie auf eine subtile Falle, die die restic-Dokumentation selbst nennt: Ein Angreifer, der gefälschte Snapshots hinzufügt, kann ein Schema wie --keep-weekly dazu bringen, echte Snapshots zu vergessen. Mit --keep-within (zum Beispiel --keep-within 30d) bleibt alles aus diesem Zeitraum erhalten, ob gefälscht oder echt.

Zusammenfassung

• restic verschlüsselt, dedupliziert und kann auf viele Arten von Speicher außerhalb Ihres Servers sichern; ist das Passwort verloren, ist alles verloren.
• init legt das Repository an, backup erstellt einen Snapshot, snapshots zeigt sie an.
• forget mit --keep-* legt fest, was Sie behalten; erst prune (oder --prune) räumt die Daten wirklich auf. Testen Sie mit --dry-run.
• check (mit --read-data-subset) prüft, restore --target stellt in ein separates Verzeichnis wieder her, mit mount können Sie sich umsehen.
• Automatisieren Sie mit einem Timer und einer Benachrichtigung, und halten Sie mindestens ein Repository außerhalb der Reichweite des Servers (append-only).

Quiz

Aufgabe

Aufgabe Z8.2: Was bleibt nach forget übrig? In der Beispieldatei restic-snapshots.txt stehen eine Liste von Snapshots und ein Aufbewahrungsschema. Bestimmen Sie, welche Snapshots nach restic forget mit diesem Schema übrig bleiben. Das Programm vergleicht mit dem festen Lösungsschlüssel.

Aufgabe O8.2: Ein Wiederherstellungstest. Legen Sie auf Ihrem eigenen Server ein restic-Repository außerhalb des Servers an, erstellen Sie ein Backup von /etc und Ihren Daten und stellen Sie ein Verzeichnis in /tmp/terug wieder her. Vergleichen Sie mit diff, notieren Sie, wie lange es gedauert hat, und beantworten Sie, wo Ihr Passwort und Ihre Speicherzugangsdaten außerhalb des Servers aufbewahrt werden.

Weiterführende Informationen

• Backup-Strategie: Die 3-2-1-Regel für Ihr eigenes Unternehmen
• restic-Dokumentation, Preparing a new repository: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html
• restic-Dokumentation, Removing backup snapshots (forget und prune): https://restic.readthedocs.io/en/stable/060_forget.html
• restic-Dokumentation, Restoring from backup: https://restic.readthedocs.io/en/stable/050_restore.html
• rest-server (append-only): https://github.com/restic/rest-server