Backup-Strategie 3-2-1 und die Regel, die keiner nennt

Die häufigste Backup-Strategie im Netz ist der Snapshot-Knopf im Kundenpanel. Der ist praktisch, kostet fast nichts und hilft gegen genau ein Problem: ein missglücktes Update. Gegen alles andere, Ausfall des Storage-Clusters, gelöschten Account, Verschlüsselungstrojaner, versehentliches DROP TABLE vor drei Wochen, hilft er nicht.

Was 3-2-1 bedeutet#

3 Kopien, das Original plus zwei Sicherungen. Klingt nach viel, ist es aber nicht: die zweite Sicherung ist die, die noch da ist, wenn die erste beim Zurückspielen als kaputt auffällt.

2 verschiedene Medien oder Systeme, nicht zweimal derselbe Storage-Cluster, nicht zweimal derselbe Anbieter, idealerweise nicht dieselbe Technik. Ein ZFS-Snapshot und eine restic-Sicherung auf ein Objektspeicher-Ziel sind zwei Medien. Zwei Snapshots sind eines.

1 Kopie außer Haus, physisch getrennt. Gegen Brand, gegen Ausfall eines ganzen Rechenzentrums, und gegen den Fall, dass ein Anbieter ein Konto sperrt.

Die vierte, ungenannte Regel: ein Backup, das nie zurückgespielt wurde, ist keins. Dazu unten mehr, weil es der Teil ist, den alle überspringen.

Was überhaupt gesichert werden muss#

Bevor Werkzeuge: die Liste. Sie ist meist kürzer, als man denkt und enthält fast immer eine Zeile, die man vergessen hätte.

Datenbanken nie über das Dateisystem sichern. Eine laufende Datenbank schreibt während der Sicherung weiter; die kopierten Dateien sind dann ein Zustand, den es nie gab. Entweder ein Dump, oder ein Dateisystem-Snapshot mit vorherigem FLUSH TABLES WITH READ LOCK bzw. dem Äquivalent der jeweiligen Datenbank.

# PostgreSQL — konsistent, komprimiert, mit Datum im Namen
sudo -u postgres pg_dumpall | zstd -9 > /var/backups/pg-$(date +%F).sql.zst

# MariaDB / MySQL
mariadb-dump --all-databases --single-transaction --quick \
  | zstd -9 > /var/backups/maria-$(date +%F).sql.zst

--single-transaction ist bei InnoDB der Unterschied zwischen „konsistent“ und „irgendwas“.

Ein konkretes Setup mit restic#

restic ist für den Einzelserver die pragmatische Wahl: ein Binary, verschlüsselt, dedupliziert, kann auf SFTP, S3-kompatible Speicher, lokale Platten und mehr schreiben.

sudo apt install -y restic

Repository anlegen, hier auf einen SFTP-Zielserver, der auch bei einem anderen Anbieter stehen darf:

export RESTIC_REPOSITORY="sftp:[email protected]:/srv/restic/web01"
export RESTIC_PASSWORD_FILE=/root/.restic-pass

# Passwort erzeugen und wegsichern — ohne dieses Passwort sind
# alle Sicherungen wertlos. Siehe Kasten weiter unten.
openssl rand -base64 48 > /root/.restic-pass
chmod 600 /root/.restic-pass

restic init

Ein Sicherungslauf mit Ausschlüssen:

restic backup \
  /etc /srv /var/www /var/backups \
  --exclude-caches \
  --exclude '/srv/**/cache' \
  --exclude '*.tmp' \
  --tag automatisch

Alte Stände aufräumen, sonst wächst das Repository unbegrenzt:

restic forget --prune \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --keep-yearly 2

Diese Aufbewahrung ist der Teil, den man an die eigene Lage anpasst. Sechs Monate klingen viel, sind aber genau die Spanne, in der ein „das war schon länger kaputt“ auffällt.

Automatisieren mit systemd statt cron#

Ein systemd-Timer hat gegenüber cron zwei Vorteile, die im Ernstfall zählen: Der letzte Lauf ist über systemctl status sichtbar, und ein verpasster Lauf wird nachgeholt.

# /etc/systemd/system/backup.service
[Unit]
Description=restic-Sicherung
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic.env
ExecStart=/usr/bin/restic backup /etc /srv /var/www /var/backups --exclude-caches --tag automatisch
ExecStart=/usr/bin/restic forget --prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6
# Nach Erfolg einen Ping an den Dead-Man-Switch: siehe Monitoring-Beitrag
ExecStartPost=/usr/bin/curl -fsS -m 10 https://kuma.example/api/push/AbCdEf
Nice=10
IOSchedulingClass=idle

# /etc/systemd/system/backup.timer
[Unit]
Description=Nächtliche restic-Sicherung

[Timer]
OnCalendar=*-*-* 03:20:00
# Zufällige Verzögerung, damit nicht zehn Maschinen gleichzeitig starten
RandomizedDelaySec=20m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl enable --now backup.timer
systemctl list-timers backup.timer      # wann läuft er das nächste Mal?

Nice und IOSchedulingClass=idle sorgen dafür, dass die Sicherung dem laufenden Dienst nicht die Platte wegnimmt. Ohne das merkt man das Backup an der Antwortzeit der Anwendung.

Die Regel, an der es scheitert: zurückspielen#

Ein Backup-Lauf, der ohne Fehler durchläuft, beweist, dass Daten geschrieben wurden. Er beweist nicht, dass sie lesbar sind, vollständig sind oder dass du weißt, wie man sie zurückholt.

Monatlich, fünf Minuten:

# 1. Integrität prüfen — liest Metadaten und Stichproben der Daten
restic check --read-data-subset=5%

# 2. Was liegt überhaupt drin?
restic snapshots

# 3. Eine echte Datei an einen Testort zurückholen
restic restore latest --target /tmp/restore-test --include /etc/nginx/nginx.conf
diff /tmp/restore-test/etc/nginx/nginx.conf /etc/nginx/nginx.conf && echo "identisch"

Einmal im Jahr, ein Nachmittag: die vollständige Übung. Neuen VPS bestellen, nur aus dem Backup wiederherstellen, Dienst starten, prüfen. Dabei lernt man immer dasselbe: Irgendetwas fehlt in der Liste. Die .env, ein Cronjob, ein Schlüssel im Home-Verzeichnis eines Dienstkontos.

Das Ergebnis dieser Übung ist wertvoller als das Backup selbst, es ist eine geschriebene Wiederherstellungsanleitung, die schon einmal funktioniert hat.

Wo Proxmox ins Bild kommt#

Wer mehrere Maschinen betreibt, will nicht auf jeder einzeln restic pflegen. Der Proxmox Backup Server sichert ganze VMs und Container inkrementell, dedupliziert über alle Gäste hinweg und kann auf ein zweites Ziel spiegeln. Details in Proxmox Backup Server richtig aufsetzen.

Die beiden schließen sich nicht aus: PBS für die Maschinen als Ganzes, restic für die Daten, die auch ohne Proxmox wieder eingespielt werden können sollen. Das sind dann tatsächlich zwei Medien.

Der Test, ob du eine Strategie hast#

Beantworte drei Fragen ohne nachzusehen:

1. Wo liegt die zweite Kopie, bei welchem Anbieter, in welchem Land?
2. Wann wurde zuletzt erfolgreich etwas zurückgespielt?
3. Wo ist das Verschlüsselungspasswort, wenn dieser Server weg ist?

Wer bei einer Frage zögert, hat an dieser Stelle die Lücke.