Der Ausfall passiert an einem Dienstag: Ransomware auf dem VPS oder einfaches „DROP TABLE“ nach einer gefährlichen Migration. Das Team versichert dem Kunden: „Wir haben Backups.“ Vier Stunden später stellten wir fest, dass die Snapshots nicht auf den gestrigen Tag zurückgingen, dass die hochgeladenen Dateien auf einer Festplatte lagen, die nicht im Lieferumfang enthalten war, und dass noch nie jemand eine vollständige Wiederherstellung getestet hatte.
Ein nützliches Backup beginnt nicht mit einem Plugin oder einem Cron. Es beginnt mit einem Satz: Im Katastrophenfall X müssen wir in Z Minuten zum Zustand Y zurückkehren, wobei höchstens N Minuten Daten verloren gehen.
Umfang vor dem Werkzeug festlegen
Listen Sie auf, was wiederbelebt werden muss:
| Komponente | Beispiel | Häufig vergessen |
|---|---|---|
| Datenbank | MySQL, PostgreSQL | Transaktionen zwischen zwei Dumps |
| Bewerbungsdateien | Uploads, Medien | Separater Objektspeicher |
| Konfiguration | .env, nginx, TLS | Geheimnisse außerhalb des Git-Repositorys |
| DNS / Zertifikate | DNS-Zone, ACME-Schlüssel | Registrar nicht „gesichert“ |
| Code | Git-Remote | Unbewachsene Äste |
Legen Sie dann RPO und RTO pro kritischer Komponente fest. Ein Vorzeige-Blog: 24-Stunden-RPO akzeptabel. Ein Store: RPO 15 Min., RTO < 2 Std.
Backup ohne RPO/RTO bedeutet Archivierung im Nebel.
3-2-1-Regel für das Web angepasst
3 Kopien – Produktion + lokale Sicherung oder Snapshot + Remote-Kopie.
2 unterstützt – Festplatte + kaltes Objekt oder andere Region.
1 Offsite – ein anderes Rechenzentrum, ein anderes Cloud-Konto, Offline-Band, falls vertraulich.
Auf gemeinsam genutzten Sites ist die Offsite-Kopie oft der einzige wirkliche Mehrwert Ihres internen Skripts – die Host-Snapshots bleiben mit ihrer Infrastruktur korreliert.
Enthaltene Backups vs. interne Skripte
| Quelle | Vorteil | Grenze |
|---|---|---|
| Snapshot VPS-Host | Schnell, integriert | Gleiche Region, kurze Dauer |
| Gemeinsames Backup „inklusive“ | Einfach | Unscharfer Bereich, langsame Wiederherstellung |
| mysqldump + rsync cron | Volle Kontrolle | Betrieb pflegen, Verschlüsselung verwalten |
| Werkzeug vom Typ Restic/Borg | Deduplizierung, verschlüsselt | Lernkurve |
Lesen Sie die SLA-Ausschlüsse: Einige Hosts sichern die Systemfestplatte, nicht jedoch die angeschlossenen Volumes. Querverweis auf unsere Umfrage zu den enthaltenen Backups, wenn Sie Angebote vergleichen.
Fehler, die die Wiederherstellung zum Scheitern bringen
Backup ohne Integritätsprüfung. Ein abgeschnittener MySQL-Dump bleibt bis zur Krise stumm.
Nur eine Aufbewahrung. Löschung täglich nach 7 Tagen ohne monatliche Löschung = keine Rückgabe vor spät erkanntem Fehler.
Geheimnisse im unverschlüsselten Backup. „.env“ in einem öffentlichen S3-Archiv = doppelter Vorfall.
Vergessen Sie die Wiederherstellungsreihenfolge. DNS vor TLS, Basis vor Workern, Objekt vor signierten URLs.
Oben: Das letzte Backup ist nicht das richtige
Dies ist der Höhepunkt, den die Zitate „Tägliches Backup inklusive“ vermeiden: Frische ist nicht gleich Sauberkeit. Stellen Sie unveränderliche Wiederherstellungspunkte bereit und testen Sie ein altes Rollback.
Entscheide dich und gehe ohne blinden Fleck voran
Schreiben Sie zwei bis drei Szenarien (Basislöschung, Ransomware, fehlerhafte Bereitstellung). Legen Sie RPO und RTO pro Szenario fest. Automatisieren Sie Exporte und verschlüsseltes Offsite-Kopieren. Planen Sie einen vierteljährlichen Restaurierungstest. Vergleichen Sie Hosts mit echtem Backup über das Verzeichnis und den Vergleich.
Häufig gestellte Fragen
Was ist der Unterschied zwischen RPO und RTO?
Der RPO legt fest, wie viele Daten Sie bereit sind zu verlieren – zum Beispiel maximal eine Stunde an Bestellungen. Die RTO legt fest, wie schnell der Dienst wieder aufgenommen werden soll – zum Beispiel nach vier Stunden. Die beiden Zahlen bestimmen die Sicherungshäufigkeit und den Wiederherstellungsvorgang.
Reichen Host-Snapshots aus?
Für ein schnelles Rollback auf derselben Infrastruktur reicht das allein oft nicht aus: dasselbe Rechenzentrum, kein Schutz vor böswilliger Löschung. Komplett mit externen und unveränderlichen Kopien.
Sollen wir die Protokolle speichern?
Nur wenn ein rechtlicher Bedarf oder eine forensische Analyse besteht. Andernfalls erhöhen sie die Rechnung, ohne dabei zu helfen, die Website wieder online zu stellen.
Geteilt: Was können wir wirklich sparen?
Oft die Basis per Export und die Dateien per FTP/rsync, sofern erlaubt. Überprüfen Sie die Ausschlüsse und Details zu „Backup inbegriffen“.
Die richtige Frage ist nicht: „Sparen wir?“ » aber „Welche Stunde von gestern können wir noch einmal richtig durchleben, und in wie lange?“