Backups einer Produktions-Website: die 3-2-1-Regel anwenden und Restores testen

Ein Backup, das nie wiederhergestellt wurde, ist kein Backup: Es ist eine Annahme. Viele Produktionsseiten verlassen sich auf einen einzigen nächtlichen Dump, der auf genau dem Server liegt, den er schützen soll, und der weder einen Plattenausfall noch eine Ransomware-Verschlüsselung noch einen Fehlgriff übersteht. Dieser Artikel legt eine bewährte Methode dar, um eine verlässliche Backup-Strategie aufzubauen und vor allem zu beweisen, dass sie funktioniert.

#Die 3-2-1-Regel, und warum sie weiterhin gilt

Die 3-2-1-Regel passt in einen Satz: drei Kopien der Daten, auf zwei verschiedenen Medien, eine davon außer Haus. Sie ist über zwanzig Jahre alt und bleibt die Referenz, weil sie nicht gegen ein Risiko schützt, sondern gegen eine ganze Familie davon.

Die Kopie außer Haus wird am häufigsten vernachlässigt, und genau sie rettet bei einem Serverraumbrand oder einer bösartigen Verschlüsselung, die alles lokal Eingebundene erreicht. Eine neuere Variante, bekannt als 3-2-1-1-0, ergänzt eine unveränderliche Kopie und ein Ziel von null Fehlern beim getesteten Restore.

#Ein Werkzeug wählen: rsync, restic oder borg

Die Wahl des Werkzeugs folgt dem echten Bedarf, nicht der Mode. Drei Familien decken die meisten Fälle einer Website ab.

Für eine selbstgehostete Website, die ihre Daten an einen entfernten Objektspeicher senden muss, bietet restic den besten Kompromiss: ein Ende-zu-Ende-verschlüsseltes Repository, eine Deduplizierung, die das Volumen begrenzt, und direkte Unterstützung für S3-Backends. Das folgende Beispiel initialisiert ein Repository und sichert dann die Dateien und eine Datenbank.

# Variables d'environnement (a stocker hors du depot versionne)
export RESTIC_REPOSITORY="s3:s3.eu-west-3.amazonaws.com/mon-bucket-sauvegardes"
export RESTIC_PASSWORD_FILE="/root/.restic-pass"

# Initialisation, une seule fois
restic init

# Sauvegarde des fichiers du site
restic backup /var/www/monsite --tag fichiers

# Sauvegarde de la base : on evite le fichier intermediaire en clair
mysqldump --single-transaction monsite \
  | restic backup --stdin --stdin-filename monsite.sql --tag base

#Automatisieren, ohne sich in Sicherheit zu wiegen

Ein manuelles Backup wird nie an dem Tag gemacht, an dem es zählt. Die Automatisierung läuft über eine geplante Aufgabe, sei es ein cron-Eintrag oder ein systemd-Timer, wobei Letzterer den Vorteil hat, sauber zu protokollieren und einen verpassten Lauf nachzuholen.

# /etc/systemd/system/backup.timer
[Unit]
Description=Sauvegarde quotidienne du site

[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true
RandomizedDelaySec=600

[Install]
WantedBy=timers.target

Die Aufbewahrungsrichtlinie wird auf der restic-Seite gesteuert, die nur eine gewählte Anzahl von Punkten pro Tag, Woche und Monat behalten und den Rest bereinigen kann. Dieser Schritt ist unverzichtbar: Ohne ihn wächst das Repository unbegrenzt, und die Speicherrechnung folgt.

# Rotation : 7 quotidiennes, 4 hebdomadaires, 6 mensuelles
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

#Der Restore-Test: der einzige Beweis, der zählt

Das ist der Schritt, den fast niemand durchführt, und der einzige, der die Absicht in eine Garantie verwandelt. Ein Repository, das nie wiederhergestellt wurde, kann beschädigt, unvollständig oder mit einem verlorenen Schlüssel verschlüsselt sein, ohne dass ein Dashboard es meldet.

Der Tag des Vorfalls ist nicht der Tag, an dem man entdeckt, dass der Restore nicht funktioniert.

Der Test läuft in einer isolierten Umgebung, niemals durch Überschreiben der Produktion. Das Ziel ist zweifach: zu prüfen, dass die Daten zurückkommen, und zu messen, wie lange es dauert, denn diese Verzögerung ist Ihr wahrer Wiederherstellungspunkt.

# Restauration d'un instantane precis vers un repertoire de controle
restic snapshots
restic restore 4a8f2c1b --target /tmp/restore-test

# Verification d'integrite du depot (a planifier aussi)
restic check --read-data-subset=5%

Ein monatlicher Restore, mit Datum und Dauer protokolliert, ist mehr wert als tausend „alles grün“-Backup-Berichte. Es ist auch der Moment, um zu prüfen, ob das Verfahren klar genug dokumentiert ist, um von jemand anderem als seinem Autor ausgeführt zu werden, an einem Abend mit Ausfall.

#Was bleibt

Eine solide Backup-Strategie lässt sich auf drei Entscheidungen herunterbrechen: die 3-2-1-Regel anwenden, um jede Risikofamilie abzudecken, mit einer expliziten Aufbewahrung automatisieren, um nicht von menschlicher Disziplin abzuhängen, und den Restore regelmäßig testen, um die Annahme in Gewissheit zu verwandeln. Diese Reflexe fügen sich natürlich in den Betrieb eines selbstgehosteten Servers ein und ergänzen das Härten auf der Sicherheitsseite.

Zum Weiterlesen: restic.