Backup-Strategie für Webprojekte

Die meisten Backup-Konzepte scheitern nicht am Sichern, sondern am Zurückspielen. Der Weg dorthin führt über drei Fragen: Was, wie oft, wohin – und dann über einen Test.

3-2-1 auf Webprojekte übersetzt

• Drei Kopien: das laufende System plus zwei Sicherungen.
• Zwei verschiedene Medien oder Anbieter: nicht beide Sicherungen beim selben Hoster.
• Eine ausserhalb: an einem Ort, der von einem kompromittierten Server aus nicht erreichbar ist.

Der dritte Punkt ist der, der im Ernstfall zählt. Wer die Sicherungen auf demselben Server ablegt, verliert sie mit ihm. Wer sie mit denselben Zugangsdaten erreichbar hält wie das System, verliert sie bei einem Einbruch mit.

Was gesichert gehört

Diese Trennung halbiert das Volumen oft deutlich, was Laufzeit und Speicherkosten senkt.

Ein funktionierendes Skript

#!/usr/bin/env bash
set -euo pipefail

TAG=$(date +%F)
ZIEL=/var/backups/example
mkdir -p "$ZIEL"

# Datenbank - konsistent ohne Tabellensperre bei InnoDB
mysqldump --single-transaction --quick --default-character-set=utf8mb4 \
  --databases example_db | gzip > "$ZIEL/db-$TAG.sql.gz"

# Uploads - inkrementell, ohne reproduzierbare Verzeichnisse
tar czf "$ZIEL/files-$TAG.tar.gz" \
  --exclude='./var/cache' --exclude='./node_modules' --exclude='./vendor' \
  -C /var/www/example .

# ausserhalb ablegen, Ziel darf nur schreiben, nicht löschen
rclone copy "$ZIEL" backup-remote:example/ --immutable

# lokale Aufbewahrung
find "$ZIEL" -name '*.gz' -mtime +14 -delete

Zwei Details, die den Unterschied machen:

set -euo pipefail bricht bei jedem Fehler ab. Ohne das läuft das Skript nach einem fehlgeschlagenen mysqldump weiter, legt eine leere Datei an und meldet Erfolg.

--immutable beim Kopieren verhindert, dass eine bestehende Sicherung überschrieben wird. Besser noch ist ein Zugang am Zielort, der Schreibrechte, aber keine Löschrechte hat – dann kann ein kompromittierter Server die Sicherungen nicht mitnehmen.

Aufbewahrung staffeln

Die wöchentliche Ebene ist die, die man sich wünscht, wenn es ernst wird. Eine Verschlüsselung durch Schadsoftware oder ein schleichender Datenverlust fällt selten am selben Tag auf. Bei einer Aufbewahrung von sieben Tagen sind dann alle Sicherungen bereits betroffen.

Der Teil, den fast alle auslassen

Restore testen. Nicht “irgendwann mal”, sondern mit Termin:

1. Eine leere Umgebung aufsetzen – lokal in einem Container reicht.
2. Die aktuelle Sicherung einspielen, ohne auf das laufende System zu schauen.
3. Die Zeit stoppen.
4. Prüfen, ob die Anwendung startet, ob Daten vollständig sind und wie alt der jüngste Datensatz ist.
5. Aufschreiben, was gefehlt hat.

Was dieser Test regelmässig zutage fördert: eine Konfigurationsdatei, die nie mitgesichert wurde, ein Zeichensatzproblem beim Import, ein fehlender Schlüssel für verschlüsselte Felder, Dateirechte, die nach dem Entpacken nicht stimmen.

Aus der gestoppten Zeit ergibt sich die realistische Wiederanlaufzeit. Die kann man kommunizieren – anders als eine Schätzung.

Überwachung der Sicherung

Ein Backup, das seit sechs Wochen scheitert, bemerkt niemand, solange niemand hinschaut. Zwei einfache Sicherungen dagegen:

# Alarm, wenn die jüngste Sicherung älter als 26 Stunden ist
find /var/backups/example -name 'db-*.sql.gz' -mtime -1 | grep -q . \
  || echo "Backup fehlt" | mail -s "Backup-Alarm example" admin@example.com

# Plausibilität der Grösse: plötzlich winzig heisst meist leerer Dump
find /var/backups/example -name 'db-*.sql.gz' -size -1M -mtime -1 \
  -exec echo "Backup verdächtig klein: {}" \;

Die zweite Prüfung fängt den Fall ab, in dem das Skript läuft, der Dump aber leer ist – beispielsweise weil das Datenbankpasswort geändert wurde. Die Datei existiert dann, ist aktuell und trotzdem wertlos.