Backup und Disaster Recovery für PHP-Websites: Ein praktischer Leitfaden

Jede PHP-Website ruht auf einem Stapel beweglicher Teile: einem Webserver, der PHP-Laufzeitumgebung, einer MySQL- oder PostgreSQL-Datenbank, Konfigurationsdateien, hochgeladenen Assets und oft Dutzenden kleinen Cron-Jobs. Jedes dieser Teile kann ausfallen – eine beschädigte Tabelle, ein wildgewordenes rm -rf, eine Ransomware-Sperre – und wenn Sie nur ein einziges Backup der Datenbank von letzter Woche haben, stecken Sie in Schwierigkeiten. Bei DigiForge haben wir mehr PHP-Seiten wiederhergestellt, als wir zählen möchten, und der Unterschied zwischen einer vierstündigen Wiederherstellung und einem viertägigen Albtraum läuft immer auf eine Sache hinaus: eine richtig durchdachte Backup- und Disaster-Recovery-Strategie.

Warum Backup allein nicht ausreicht

Viele Teams verwechseln Backup mit Disaster Recovery. Ein Backup ist eine periodische Kopie von Daten. Disaster Recovery ist der gesamte Prozess, Ihre Anwendung wieder online zu bringen – Daten wiederherstellen, Dienste neu konfigurieren, Traffic umleiten und validieren, dass alles funktioniert. Wie ein IT-Resilienzbericht es formulierte: „Der Schutz Ihrer Daten durch Backups reicht nicht mehr aus, um zu überleben“ (Quelle). Ein Backup ohne getesteten Wiederherstellungsplan ist nur eine Versicherung, die Sie noch nicht gelesen haben.

Im PHP-Kontext ist der Unterschied eklatant. Ihr Datenbank-Backup mag vollkommen intakt sein, aber wenn Sie nicht wissen, wie Sie Apache oder Nginx auf die wiederhergestellte Datenbank ausrichten, die .env-Zugangsdaten ändern oder den PHP-Opcache neu aufbauen, sind Sie immer noch offline. Und Ausfallzeiten kosten bekanntlich Geld und Vertrauen. Ein umfassender Disaster-Recovery-Plan (DR) muss jede Schicht Ihres Server-Stacks abdecken, nicht nur die Daten.

Der Backup- und Recovery-Stack für PHP-Seiten

Wir unterteilen das Backup einer PHP-Anwendung in fünf verschiedene Schichten. Fehlt eine davon, können die anderen nutzlos werden:

1. Code und Versionskontrolle (Git-Repositories, einschließlich Tags und Branches).
2. Datenbank-Dumps (MySQL, PostgreSQL oder MariaDB).
3. Webserver-Konfiguration (Nginx/Apache Virtual Hosts, SSL-Zertifikate, PHP-FPM-Pools).
4. Anwendungskonfiguration (.env, Konfigurationsdateien, hartcodierte Zugangsdaten).
5. Benutzer hochgeladene Inhalte (Bilder, PDFs, alle Dateien, die außerhalb der Datenbank gespeichert sind).

Lassen Sie uns jede Schicht mit praktischen Empfehlungen durchgehen.

1. Code und Versionskontrolle

Ihr Anwendungscode sollte in einem Git-Repository leben – keine Ausnahmen. Aber ein Git-Push ist kein Backup. Wir haben Teams erlebt, die sich auf einen einzigen Remote-Branch verlassen haben und Wochen Arbeit verloren, als ein Force-Push oder ein beschädigtes Repository zuschlug. Nutzen Sie einen Git-Hosting-Anbieter (GitHub, GitLab, Bitbucket) und richten Sie automatisierte Spiegel auf einen zweiten Standort ein. Für Produktionsbereitstellungen taggen Sie jedes Release. So müssen Sie nicht raten, welcher Commit live war, wenn Sie auf einen bekannten guten Zustand zurückrollen müssen.

2. Datenbank-Backups

Datenbank-Backups sind das Wichtigste und werden am meisten vernachlässigt. Ein tägliches mysqldump in ein lokales Verzeichnis ist besser als nichts, aber wir haben gesehen, dass solche Backups die Festplatte füllen und stillschweigend aufhören zu laufen. Automatisieren Sie Ihre Dumps mit einem Skript, das alte Backups rotiert, komprimiert und an einen externen Standort versendet – zu S3, Backblaze oder einem separaten Server. Verwenden Sie mysqldump --single-transaction für InnoDB-Tabellen, um Lese-Sperren zu vermeiden, und testen Sie Ihre Wiederherstellung regelmäßig. Ein Backup, das nicht wiederhergestellt werden kann, ist wertlos.

3. Server- und Webserver-Konfiguration

Ihre PHP-Site besteht aus mehr als nur Code und Daten. Nginx- oder Apache-Konfigurationsdateien, PHP-FPM-Pool-Einstellungen, SSL-Zertifikate und Cron-Job-Definitionen sind alle einzigartig für Ihren Server. Wir speichern diese in einem separaten Git-Repository (oder als Teil des Anwendungs-Repositorys unter einem deploy/-Verzeichnis) und sichern sie zusammen mit dem Rest. Dienste wie Certbot erneuern Let's-Encrypt-Zertifikate automatisch, aber wenn Ihr Server stirbt, sind diese Zertifikate weg. Sichern Sie /etc/letsencrypt/ oder wechseln Sie zu DNS-basierter Validierung, die einen Neubau überlebt.

4. Umgebungs- und Anwendungskonfiguration

PHP-Anwendungen enthalten oft eine .env-Datei mit Datenbankzugangsdaten, API-Schlüsseln und Geheimnissen. Diese dürfen niemals in der Versionskontrolle landen. Für die Produktion verwenden wir einen Secrets-Manager (wie HashiCorp Vault oder envkey), aber mindestens sollten Sie eine verschlüsselte Kopie der .env-Datei in Ihrem Backup-System aufbewahren. Wenn Sie diese Datei verlieren, stellen Sie Ihre Website nicht wieder her – Sie bauen sie neu auf.

5. Benutzer-Uploads und Medien

Bilder, PDFs und andere Uploads werden oft in einem public/uploads-Verzeichnis gespeichert. Sie wachsen schnell und können Datenbank-Backups aufblähen, wenn sie als BLOBs gespeichert werden. Best Practice: Halten Sie Uploads auf einem separaten Volume oder Objektspeicher (S3, DigitalOcean Spaces). Wenn sie sich auf dem Server-Dateisystem befinden, nehmen Sie dieses Verzeichnis in Ihr Offsite-Backup auf. Verwenden Sie rsync oder rclone, um täglich eine Synchronisation mit der Cloud durchzuführen.

Automatisierung und Testen Ihres Wiederherstellungsplans

Eine Backup-Strategie ist nur so gut wie ihre Wiederherstellung. Wir sind schon zu vielen Post-Mortems gekommen, in denen der Kunde sagte: „Wir haben Backups“, aber nie versucht hat, sie zu nutzen. Disaster Recovery ist ein Prozess, kein Produkt. Sie müssen aufschreiben – und, noch wichtiger, proben – wie Sie Ihre PHP-Website wiederherstellen.

• Schreiben Sie ein Runbook. Dokumentieren Sie jeden Schritt: wo Backups gespeichert sind, wie die Datenbank wiederhergestellt wird, welche Befehle den Webserver neu aufbauen, wie DNS aktualisiert wird, wenn sich Ihre IP ändert.
• Automatisieren Sie Wiederherstellungen. Verwenden Sie Skripte oder Orchestrierungswerkzeuge (Ansible, Puppet oder sogar ein einfaches Bash-Skript), um einen neuen Server bereitzustellen und Ihre Anwendung aus Backups wiederherzustellen. Wenn Sie nicht innerhalb einer Stunde einen Klon hochfahren können, ist Ihr DR-Plan zu langsam.
• Testen Sie vierteljährlich. Stellen Sie Ihren gesamten PHP-Stack auf einem frischen Server (einer neuen VPS oder lokalen VM) wieder her und überprüfen Sie, ob die Website funktioniert. Testen Sie DNS-Propagation, SSL, Datenbankverbindungen, Cron-Jobs und alle Benutzerabläufe. Beheben Sie alles, was kaputt geht.

Unserer Erfahrung nach sind die häufigsten Fehler bei einer Wiederherstellungsübung nicht übereinstimmende Anmeldedaten (hartcodierte Datenbankpasswörter, die nicht zur wiederhergestellten .env passen), fehlende PHP-Erweiterungen und unvollständige Uploads. Jeder Fehler ist ein Geschenk – er zeigt eine Lücke auf, die Sie vor einem echten Desaster schließen können.

„Ein Backup ohne getesteten Wiederherstellungsplan ist nur eine Hoffnung.“ — DigiForge-Engineering-Prinzip

Auswahl von Speicherorten und Formaten

Die alte 3-2-1-Regel gilt weiterhin: drei Kopien Ihrer Daten, auf zwei verschiedenen Medien, eine Kopie außerhalb des Standorts. Für PHP-Websites ist ein gängiges Setup: (1) das lokale Backup-Skript des Live-Servers, (2) ein externer Cloud-Bucket und (3) ein Kaltlager-Archiv (z. B. Glacier) für monatliche Snapshots. Verschlüsseln Sie Backups mit GPG oder clientseitiger Verschlüsselung, bevor Sie sie an Dritte hochladen.

Inkrementelle Backups sparen Bandbreite und Speicherplatz, erhöhen aber die Komplexität der Wiederherstellung. Für eine mittelgroße PHP-Site ist ein täglicher vollständiger Datenbank-Dump plus stündliche Binärlogs (falls erforderlich) ein guter Kompromiss. Dateisystem-Backups können inkrementell über rsync erfolgen – stellen Sie nur sicher, dass Ihre Tools einen konsistenten Zustand aus den Inkrementen wiederherstellen können.

Wenn der Ernstfall eintritt: Das Recovery-Runbook

Simulieren wir den Worst Case: Ein Ransomware-Angriff verschlüsselt Ihr PHP-Webroot und Ihre Datenbank. Hier ist der grobe Ablauf der Wiederherstellung, den wir bei DigiForge verwenden:

1. Infizierten Server isolieren – sämtlichen externen Zugriff unterbinden, ggf. Snapshot für Forensik erstellen.
2. Sauberen Server bereitstellen – eine frische VPS mit demselben Betriebssystem und derselben PHP-Version.
3. Code aus Git wiederherstellen – das getaggte Release klonen, das vor dem Angriff lief.
4. Konfiguration wiederherstellen – .env, Webserver-Konfigurationen, SSL-Zertifikate kopieren (oder neu ausstellen).
5. Datenbank wiederherstellen – den letzten sauberen Dump importieren, dann Binlogs bis zum Infektionszeitpunkt (falls vorhanden) abspielen.
6. Uploads wiederherstellen – rsync vom Backup-Speicher in das Uploads-Verzeichnis des neuen Servers.
7. Alles testen – Health Checks durchführen, Datenbankverbindungen prüfen, Cron-Jobs testen.
8. DNS umstellen – die Domain auf die IP des neuen Servers zeigen (vorher TTL senken).
9. Überwachen – Logs und Verfügbarkeit 24 Stunden lang beobachten. Recovery erst nach anhaltendem Grün erklären.

Dieser gesamte Prozess kann 2–4 Stunden dauern, wenn Ihre Backups gut organisiert sind und Sie geübt haben. Ohne Übung kann er sich auf Tage ausdehnen.

Eine Kultur der Wiederherstellung aufbauen

Disaster Recovery ist kein einmaliges Projekt – es ist eine fortlaufende Praxis. Jedes Mal, wenn Sie Ihre PHP-Version aktualisieren, einen neuen Cron-Job hinzufügen oder eine Webserver-Direktive ändern, aktualisieren Sie Ihr Runbook und testen erneut. Wir haben zu oft erlebt, dass Teams Backups als reine Checkliste betrachten. Eine echte DR-Strategie ist in Ihre Deployment-Pipeline, Ihr Monitoring und die Muskelgedächtnis Ihres Teams eingewoben.

Wenn Sie für eine PHP-Website verantwortlich sind, beginnen Sie noch heute. Überprüfen Sie Ihre Backup-Abdeckung für alle fünf Ebenen, automatisieren Sie, was möglich ist, und planen Sie Ihre erste Wiederherstellungsübung. Und wenn Sie eine zweite Meinung zu Ihrer Strategie wünschen, kontaktieren Sie DigiForge. Wir haben genug PHP-Seiten aufgebaut und wiederhergestellt, um zu wissen, was funktioniert – und was nicht.