Kurz gesagt: Eine belastbare Backup-Strategie für Server folgt der 3-2-1-Regel: drei Kopien, zwei Speicherarten, eine Kopie außer Haus. Damit Backups auch einen Angriff überstehen, braucht mindestens eine Kopie Schutz vor Löschung durch den Server selbst. Und erst ein erfolgreicher Wiederherstellungstest zeigt, dass die Sicherung im Ernstfall funktioniert.
Was die 3-2-1-Regel bedeutet
Die 3-2-1-Regel ist ein einfacher, seit Jahren bewährter Grundsatz für Datensicherung:
- 3 Kopien: die Originaldaten und zwei Sicherungen.
- 2 Speicherarten: zum Beispiel lokale Platte und Objektspeicher, oder Server-Speicher und Band.
- 1 Kopie außer Haus: an einem anderen Standort, bei einem anderen Anbieter oder offline.
Für Webserver heißt das konkret: Eine Sicherung auf derselben Festplatte wie die Website zählt nicht als eigenständige Kopie. Fällt der Server aus oder wird er kompromittiert, sind beide verloren. Für die Geschäftsführung lautet die Kernfrage deshalb nicht „Haben wir Backups?“, sondern „Können wir den Betrieb aus einer Kopie wiederherstellen, die der Vorfall nicht erreicht hat?“
Eine Backup-Strategie für Server, die einen Angriff übersteht
Angreifer wissen, dass Backups ihre Arbeit zunichtemachen. Wer Zugriff auf einen Server hat, sucht deshalb oft auch nach Sicherungen, um sie zu löschen oder zu verschlüsseln. Eine moderne Strategie erweitert die 3-2-1-Regel daher häufig zu 3-2-1-1-0: eine Kopie zusätzlich offline oder unveränderbar, und null Fehler beim Wiederherstellungstest.
Drei Grundsätze machen Backups widerstandsfähig:
- Pull statt Push: Ein separates Backup-System holt die Daten vom Webserver ab. Der Webserver selbst hat keine Zugangsdaten, mit denen er Backups löschen könnte.
- Unveränderbarkeit: Objektspeicher mit Aufbewahrungssperre oder Snapshots, die sich für eine festgelegte Zeit nicht löschen lassen.
- Getrennte Zugänge: Das Backup-Konto ist nicht dasselbe wie das Hosting-Kundenkonto und hat einen eigenen zweiten Faktor.
Verschlüsseln Sie Backups, die außer Haus liegen, und verwahren Sie den Schlüssel getrennt. Ein verlorener Schlüssel macht das Backup unbrauchbar, ein mitgespeicherter Schlüssel macht die Verschlüsselung wertlos.
Was gesichert werden muss
Bei Webservern wird oft nur der Webroot gesichert. Für eine vollständige Wiederherstellung fehlen dann wichtige Teile.
| Bereich | Beispiele | Hinweis |
|---|---|---|
| Anwendungsdateien | Webroot, Uploads, Themes, Erweiterungen | Uploads ändern sich häufig |
| Datenbanken | MySQL/MariaDB, PostgreSQL | konsistent sichern, nicht nur Dateien kopieren |
| Konfiguration | Webserver, PHP-FPM-Pools, php.ini, Cronjobs | nötig für schnellen Neuaufbau |
| Zertifikate und Schlüssel | TLS-Zertifikate, Anwendungsschlüssel | verschlüsselt und getrennt ablegen |
| Dokumentation | Zugänge, Abhängigkeiten, Ablauf der Wiederherstellung | ohne sie dauert jeder Neuaufbau länger |
Beispiel: Datenbank und Dateien sichern
Das folgende Beispiel zeigt die Grundbausteine einer täglichen Sicherung. In der Praxis übernimmt ein Backup-Werkzeug mit Verschlüsselung, Deduplizierung und Aufbewahrungsregeln die Übertragung außer Haus.
#!/bin/bash
set -euo pipefail
DATUM=$(date +%F)
ZIEL=/srv/backup/$DATUM
mkdir -p "$ZIEL"
chmod 700 "$ZIEL"
# Datenbank konsistent sichern; Zugangsdaten aus geschützter Datei, nicht im Befehl
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
--single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"
# Anwendungsdateien und Konfiguration
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d
# Prüfsummen für spätere Kontrolle
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
Die Datei .backup-my.cnf enthält die Zugangsdaten eines Datenbankbenutzers, der nur lesen darf, und hat die Rechte 0600. --single-transaction sorgt bei InnoDB-Tabellen für einen konsistenten Stand, ohne den Shop anzuhalten.
Danach überträgt ein separates System die Sicherung außer Haus. Wichtig ist, dass dieser Schritt überwacht wird: Ein Backup-Auftrag, der seit Tagen still fehlschlägt, fällt sonst erst im Ernstfall auf. Eine tägliche Meldung über Erfolg, Größe und Dauer reicht, solange jemand sie liest und Abweichungen nachgeht.
Nutzen Sie zusätzlich Backups oder Snapshots Ihres Hosters, klären Sie schriftlich, wie lange diese aufbewahrt werden, ob Sie selbst wiederherstellen können und ob die Sicherungen bei einem gekündigten oder gesperrten Konto erhalten bleiben. Diese Kopien sind eine gute Ergänzung, ersetzen aber keine eigene, unabhängige Sicherung.
Aufbewahrung: warum ältere Stände nach PHP2Shell wichtig sind
Nach einem Angriff ist nicht das jüngste Backup das wertvollste, sondern das jüngste saubere. Bei PHP2Shell wurde laut Medienberichten am 17.10.2026 ein erster Angriffsversuch beobachtet, die Patches erschienen am 21.10.2026. Wer nur sieben Tage aufbewahrt, hat womöglich keinen Stand mehr, der sicher vor dem möglichen Einbruch liegt.
Ein bewährtes Schema kombiniert mehrere Zeiträume, zum Beispiel tägliche Sicherungen für einige Wochen, wöchentliche für einige Monate und monatliche für ein Jahr. Die genauen Zeiträume richten sich nach Ihrem Schutzbedarf und nach Löschpflichten aus dem Datenschutz.
Wichtig ist auch: Ein Backup aus der Zeit nach einem Einbruch kann Webshells oder veränderte Dateien enthalten. Spielen Sie nach einem Vorfall nie blind zurück, sondern vergleichen Sie Dateien mit einem sauberen Stand und prüfen Sie sie, bevor die Website wieder online geht. Hinweise, worauf Sie achten sollten, finden Sie unter Anzeichen einer Kompromittierung. Ein Patch entfernt keine eingeschleuste Schadsoftware, und ein Backup tut das auch nicht von allein.
Wiederherstellung testen und dokumentieren
Ein Backup ohne Test ist eine Annahme. Erst die Wiederherstellung zeigt, ob alle Teile vorhanden sind, ob der Schlüssel funktioniert und wie lange der Vorgang tatsächlich dauert.
- Spielen Sie regelmäßig eine vollständige Sicherung auf einer Testumgebung ein, inklusive Datenbank und Konfiguration.
- Prüfen Sie, ob die Website danach vollständig funktioniert: Anmeldung, Bestellungen, Formulare, Mails.
- Messen Sie die Dauer und halten Sie fest, welche Schritte manuell waren. Vergleichen Sie das Ergebnis mit der Zeit, die Ihr Betrieb höchstens ohne Website auskommt.
- Legen Sie die Anleitung zur Wiederherstellung dort ab, wo sie auch bei ausgefallenem Server erreichbar ist, zum Beispiel im IT-Notfallplan.
Wie hilft PHP SOS konkret?
- Wir prüfen Ihre bestehenden Backups auf Vollständigkeit, Aufbewahrung, Trennung vom Server und Schutz vor Löschung.
- Wir richten eine 3-2-1-Sicherung mit unveränderbarer Kopie ein und testen die Wiederherstellung gemeinsam mit Ihnen.
- Nach einem Vorfall identifizieren wir den letzten sauberen Stand und stellen ihn im Zuge der Malware-Entfernung auf einem gepatchten System wieder her.
- Im Security-Wartungsvertrag überwachen wir die Sicherungen laufend und führen regelmäßige Wiederherstellungstests durch.
Häufige Fragen
Was bedeutet die 3-2-1-Regel bei Backups?
Drei Kopien Ihrer Daten, auf zwei unterschiedlichen Speicherarten, davon eine an einem anderen Ort. Die Regel sorgt dafür, dass weder ein Hardwaredefekt noch ein Angriff oder ein Brand alle Kopien gleichzeitig trifft.
Reicht das Backup meines Hosters?
Es ist eine gute Ergänzung, aber selten ausreichend. Klären Sie, wie lange der Hoster Stände aufbewahrt, ob Sie selbst wiederherstellen können und ob ein Angreifer mit Ihrem Kundenkonto die Backups löschen könnte. Eine eigene, unabhängige Kopie ist empfehlenswert.
Kann ich nach einem Hack einfach das letzte Backup einspielen?
Nur mit Vorsicht. Das letzte Backup kann bereits Schadcode enthalten, und die Lücke, über die der Angreifer kam, ist danach noch offen. Erst die Ursache klären und schließen, dann einen geprüften Stand auf ein gepatchtes System zurückspielen.
Wie oft sollte ich die Wiederherstellung testen?
Regelmäßig und nach größeren Änderungen am System. Ein fester Rhythmus, etwa eine vollständige Wiederherstellung pro Quartal auf einer Testumgebung, hat sich bewährt. Wichtig ist, dass der Test dokumentiert wird und Lücken behoben werden.