Ein WordPress-Backup ist erst dann wirklich wertvoll, wenn sich die Website damit wiederherstellen lässt. Eine ZIP-Datei irgendwo auf dem Server, ein gelegentlicher Datenbankexport oder die Aussage des Hosters, dass „automatisch gesichert“ werde, reichen deshalb als Backup-Strategie nicht aus.
Für eine typische WordPress-Installation werden mindestens zwei Dinge benötigt: die Dateien der Website und ihre Datenbank. WordPress weist in seiner eigenen Administrationsdokumentation ausdrücklich darauf hin, dass beide Bestandteile zu einer vollständigen Sicherung gehören. (WordPress Developer Resources)
Hinzu kommen Fragen, die mindestens genauso wichtig sind: Wie aktuell muss die Sicherung sein? Wo wird sie gespeichert? Wie lange werden ältere Versionen aufbewahrt? Was passiert, wenn der komplette Server ausfällt? Und hat irgendwann jemand ausprobiert, ob sich die Sicherung tatsächlich zurückspielen lässt?
Ein gutes WordPress-Backup beantwortet all diese Fragen, bevor etwas passiert.
Warum ein WordPress-Backup aus zwei Teilen besteht
Eine WordPress-Website besteht nicht aus einer einzigen Datei oder Datenbank.
In der Datenbank befinden sich unter anderem Beiträge, Seiten, Kommentare und viele Einstellungen. Die Website-Dateien enthalten dagegen beispielsweise Themes, Plugins, hochgeladene Medien, Konfigurationsdateien und zusätzlichen Programmcode. WordPress dokumentiert diese Trennung ausdrücklich: Das Herunterladen des WordPress-Verzeichnisses sichert normalerweise nicht automatisch die Datenbank, weil diese separat in MySQL oder MariaDB gespeichert wird. (WordPress Developer Resources)
Vereinfacht sieht eine vollständige Sicherung deshalb so aus:
WordPress-Backup
│
├── Datenbank
│
└── Dateien
Fehlt einer dieser beiden Bestandteile, kann die Wiederherstellung unvollständig sein.
Was steckt in der WordPress-Datenbank?
WordPress speichert einen erheblichen Teil seiner Inhalte und Einstellungen in einer relationalen Datenbank.
Dort befinden sich typischerweise Beiträge und Seiten, Kommentare, Benutzerinformationen, Kategorien, Schlagwörter, Optionen und zahlreiche Metadaten. Plugins können zusätzliche Informationen in bestehenden oder eigenen Tabellen speichern. WordPress nennt Beiträge, Seiten, Kommentare und Einstellungen ausdrücklich als typische Inhalte einer Datenbanksicherung. (WordPress Developer Resources)
Bei einer einfachen Informationswebsite ist die Datenbank möglicherweise nur wenige Megabyte groß.
Bei Shops, Mitgliedersystemen oder umfangreichen Portalen kann sie dagegen geschäftskritische Informationen enthalten.
Ein aktuelles Datenbankbackup ist deshalb häufig der zeitkritischste Teil der gesamten Sicherung.
Was gehört zum Datei-Backup?
Auf dem Webserver liegen die eigentlichen WordPress-Dateien.
Dazu gehören der WordPress-Core, Themes, Plugins, Bilder und andere Uploads, zusätzlicher JavaScript- oder PHP-Code sowie Konfigurationsdateien. WordPress empfiehlt insbesondere, das Verzeichnis wp-content, die Datei wp-config.php und gegebenenfalls .htaccess zu berücksichtigen. (WordPress Developer Resources)
wp-content ist besonders wichtig, weil dort normalerweise viele projektspezifische Bestandteile liegen:
wp-content/
├── themes/
├── plugins/
└── uploads/
Dort befinden sich also das Design, installierte Erweiterungen und hochgeladene Medien.
Muss der komplette WordPress-Core gesichert werden?
Nicht zwingend jede Core-Datei ist unwiederbringlich.
Die WordPress-Core-Dateien können grundsätzlich erneut aus einer passenden WordPress-Version bezogen werden. WordPress weist selbst darauf hin, dass gerade wp-content und wp-config.php besonders wichtig sind, weil der Core grundsätzlich ersetzbar ist. (WordPress Developer Resources)
Trotzdem kann eine vollständige Dateisicherung die Wiederherstellung erheblich vereinfachen.
Dann muss im Ernstfall nicht erst rekonstruiert werden, welche Versionen und individuellen Dateien vorhanden waren.
Speicherplatz ist heute vergleichsweise günstig. Bei normalen WordPress-Seiten spricht deshalb wenig dagegen, vollständige konsistente Sicherungen anzulegen.
Dateien und Datenbank sollten zusammenpassen
Stell dir einen stark frequentierten Shop vor.
Um 12:00 Uhr wird die Datenbank gesichert.
Um 18:00 Uhr werden die Dateien gesichert.
Dazwischen wurden Plugins aktualisiert, Bestellungen abgewickelt und Bilder hochgeladen.
Beide Sicherungen stammen zwar vom selben Tag, bilden aber möglicherweise nicht denselben Zustand ab.
WordPress empfiehlt deshalb, Dateien und Datenbank als zusammengehöriges Backup-Set zu betrachten und zeitlich möglichst eng miteinander zu sichern. (WordPress Developer Resources)
Bei einer kleinen Informationsseite ist eine Abweichung von wenigen Minuten meist belanglos.
Bei dynamischen Systemen kann sie entscheidend sein.
Wie oft sollte WordPress gesichert werden?
Es gibt keine sinnvolle Backup-Frequenz, die für jede Website gleich ist.
Die entscheidende Frage lautet:
Wie viele Daten darf ich im schlimmsten Fall verlieren?
Ein Blog, auf dem einmal pro Monat ein Artikel erscheint, hat andere Anforderungen als ein Shop, in dem jede Minute Bestellungen eingehen.
Wenn eine Website maximal einen Tag Daten verlieren darf, reicht ein wöchentliches Datenbankbackup offensichtlich nicht.
Bei einem häufig aktualisierten System können tägliche oder noch häufigere Datenbanksicherungen erforderlich sein.
Die Backup-Frequenz sollte deshalb aus der möglichen Verlustmenge abgeleitet werden – nicht aus einer pauschalen Empfehlung.
Dateien und Datenbank müssen nicht immer gleich häufig gesichert werden
Auch innerhalb derselben Website kann eine unterschiedliche Frequenz sinnvoll sein.
Die Datenbank eines Shops verändert sich ständig.
Das Theme und die Plugins ändern sich dagegen möglicherweise nur während geplanter Wartungsarbeiten.
Daraus könnte beispielsweise entstehen:
Datenbank → sehr häufig
Uploads → täglich
Themes/Plugins → täglich oder nach Änderungen
vollständiges Backup → regelmäßig
Das konkrete Konzept hängt von der Website ab.
Wichtig ist nur, dass sich aus den vorhandenen Sicherungen ein konsistenter Zustand rekonstruieren lässt.
Vor Updates sollte ein Backup vorhanden sein
Ein Update von WordPress, Themes oder Plugins verändert Programmcode und kann teilweise auch Datenbankstrukturen verändern.
WordPress empfiehlt deshalb ausdrücklich, Datenbank und Dateien vor einem manuellen Upgrade zu sichern und zu überprüfen, ob die Sicherungen tatsächlich vorhanden und verwendbar sind. (WordPress Developer Resources)
Das gilt insbesondere vor größeren Änderungen.
Ein Backup vor einem Update ist dabei keine Misstrauenserklärung gegenüber WordPress.
Es ist ein normaler Bestandteil professioneller Änderungsprozesse.
Ein Backup sollte vor der Änderung erstellt werden, nicht danach
Das klingt trivial, wird aber erstaunlich häufig falsch gemacht.
Wenn die Website bereits beschädigt ist, kann eine anschließend erzeugte Sicherung nur noch den beschädigten Zustand dokumentieren.
Vor einem:
Plugin-Update,
Themewechsel,
WordPress-Update,
PHP-Upgrade,
größeren Import,
Datenbankeingriff
oder umfangreichen Umbau
sollte deshalb klar sein, auf welchen funktionierenden Zustand zurückgegangen werden kann.
Das Backup des Hosters ist hilfreich
Viele Hostinganbieter erstellen automatische Sicherungen.
Das ist ausgezeichnet und kann im Ernstfall sehr wertvoll sein.
WordPress nennt vom Hostinganbieter bereitgestellte Backup-Werkzeuge ausdrücklich als mögliche Sicherungsmethode. Gleichzeitig empfiehlt die Dokumentation, auch eigene Kopien der Website-Dateien anzulegen. (WordPress Developer Resources)
Der Hoster kann damit eine wichtige Backup-Ebene bilden.
Er sollte aber nicht blind als vollständige Strategie vorausgesetzt werden.
Was sollte ich über Hoster-Backups wissen?
Die entscheidenden Informationen stehen nicht auf der Werbeseite unter „automatische Backups“.
Wichtig ist vielmehr:
Wie oft wird gesichert?
Wie lange werden Versionen aufbewahrt?
Sind Dateien und Datenbank enthalten?
Kann ich selbst wiederherstellen?
Kann ich Sicherungen herunterladen?
Wo werden sie gespeichert?
Was passiert bei Kündigung oder Sperrung des Hostingkontos?
Erst mit diesen Informationen lässt sich beurteilen, welche Rolle das Hoster-Backup innerhalb der eigenen Strategie spielen kann.
Ein Backup auf demselben Server schützt nicht vor allem
Angenommen, deine Website befindet sich auf Server A.
Dort liegt außerdem:
/backups/wordpress.zip
Damit bist du gut gegen einen versehentlich gelöschten Plugin-Ordner geschützt.
Fällt aber der gesamte Server aus oder geht der Zugriff auf das Hostingkonto verloren, kann gleichzeitig auch das Backup betroffen sein.
Eine wichtige Sicherung sollte deshalb nicht ausschließlich vom System abhängen, das sie schützen soll.
Das ist einer der zentralen Grundgedanken jeder vernünftigen Backup-Architektur.
Offsite-Backups schaffen eine zweite Ebene
Offsite bedeutet, dass mindestens eine Sicherung außerhalb der eigentlichen Hostingumgebung gespeichert wird.
Das könnte beispielsweise sein:
Produktivserver
↓
Backup
↓
separater Speicherort
Der separate Speicher kann ein anderer Server, ein Object-Storage-Dienst, ein NAS oder eine andere geeignete Backup-Infrastruktur sein.
Damit wird ein vollständiger Ausfall des Produktivsystems wesentlich beherrschbarer.
Synchronisation ist nicht automatisch ein Backup
Dieser Unterschied ist enorm wichtig.
Angenommen, ein Ordner wird automatisch mit einem zweiten Speicherort synchronisiert.
Du löschst versehentlich eine wichtige Datei.
Die Synchronisation erledigt nun genau ihre Aufgabe – und löscht die Datei auch am zweiten Ort.
Bei echter Versionierung wäre dagegen möglicherweise noch eine ältere Fassung vorhanden.
Synchronisation bedeutet, Datenstände anzugleichen.
Backup bedeutet, einen früheren Zustand wiederherstellen zu können.
Ein System kann beides miteinander kombinieren. Die Begriffe sollten trotzdem nicht verwechselt werden.
Ein Server-Snapshot ist ebenfalls nicht dasselbe wie eine vollständige Backup-Strategie
Viele VPS- und Cloud-Anbieter bieten Snapshots an.
Ein Snapshot kann den Zustand einer virtuellen Maschine oder eines Datenträgers zu einem bestimmten Zeitpunkt festhalten.
Das ist ausgesprochen praktisch.
Bei einem misslungenen Update kann sich der gesamte Server möglicherweise sehr schnell zurücksetzen lassen.
Trotzdem sollte ein Snapshot nicht zwingend die einzige Sicherungsform sein.
Wenn das Kundenkonto, die Cloud-Plattform oder die gesamte Instanz betroffen ist, kann die Abhängigkeit weiterhin bestehen.
Snapshots sind hervorragend als zusätzliche Wiederherstellungsebene.
Backup-Plugins können die Sicherung automatisieren
WordPress-Plugins können Datenbank und Dateien sichern, Sicherungen planen und teilweise auf externe Speicher übertragen.
Das ist besonders für Betreiber praktisch, die keinen eigenen Server verwalten.
Ein gutes Backup-Plugin kann beispielsweise nachts automatisch eine Sicherung erzeugen und an einen unabhängigen Speicherort übertragen.
Dadurch wird eine Aufgabe automatisiert, die sonst regelmäßig manuell durchgeführt werden müsste.
Das Grundprinzip bleibt jedoch unabhängig vom Plugin:
Entscheidend ist das Ergebnis, nicht das Werkzeug.
Ein Plugin-Backup läuft innerhalb von WordPress
Das bringt einen wichtigen Unterschied mit sich.
Ein WordPress-Backup-Plugin arbeitet innerhalb derselben Anwendung, die es sichern soll.
Wenn WordPress schwer beschädigt ist oder gar nicht mehr ausgeführt werden kann, lässt sich das Plugin möglicherweise ebenfalls nicht mehr verwenden.
Serverseitige Sicherungen arbeiten dagegen auf einer anderen Ebene.
Deshalb können mehrere Backup-Ebenen sinnvoll sein:
WordPress-Backup
+
Hosting-/Server-Backup
+
externe Kopie
Nicht jede Website braucht maximale Redundanz. Aber verschiedene Sicherungswege reduzieren gemeinsame Ausfallursachen.
Ein Datenbank-Dump ist ein wichtiger Baustein
Eine WordPress-Datenbank lässt sich beispielsweise über Werkzeuge wie phpMyAdmin oder direkt über MySQL/MariaDB exportieren.
Dabei entsteht typischerweise eine SQL-Datei, gegebenenfalls komprimiert als .gz oder .bz2. WordPress beschreibt sowohl phpMyAdmin als auch Kommandozeilenwerkzeuge als mögliche Wege für Datenbanksicherung und Wiederherstellung. (WordPress Developer Resources)
Eine solche Datei enthält den gesicherten Datenbankzustand.
Zur Wiederherstellung muss sie wieder in eine passende Datenbank importiert werden.
Ein WordPress-Export ist kein vollständiges Website-Backup
Unter Werkzeuge → Daten exportieren kann WordPress eine XML-Datei im WXR-Format erzeugen.
Diese kann unter anderem Beiträge, Seiten, benutzerdefinierte Inhaltstypen, Kommentare, benutzerdefinierte Felder, Kategorien, Schlagwörter und Benutzerinformationen enthalten. (WordPress.org)
Das ist nützlich für Migrationen und Inhaltsübertragungen.
Es ist aber nicht dasselbe wie eine vollständige Sicherung von Dateien und Datenbank.
Wer lediglich den WordPress-Export herunterlädt, hat dadurch beispielsweise noch kein vollständiges Abbild seiner Plugins, Themes und Serverkonfiguration.
Ein vollständiges Backup muss wiederherstellbar sein
Ein Ordner voller ZIP-Dateien vermittelt ein angenehmes Gefühl.
Entscheidend wird aber erst der Moment der Wiederherstellung.
Dafür müssen beispielsweise geklärt sein:
Wo liegt die richtige Sicherung?
Wie wird die Datenbank importiert?
Wie kommen die Dateien zurück?
Welche Zugangsdaten werden benötigt?
Welche Domain- oder Serverkonfiguration muss vorhanden sein?
WordPress dokumentiert für Datenbank-Backups ausdrücklich den Wiederherstellungsweg durch erneuten Import in MySQL oder MariaDB. (WordPress Developer Resources)
Ein Backup ohne bekannten Restore-Prozess ist deshalb unvollständig geplant.
Restore-Tests sind wichtiger als schöne Backup-Berichte
Ein Backup-System kann jeden Morgen eine grüne Meldung schicken:
„Backup erfolgreich.“
Das beweist zunächst nur, dass ein Prozess ohne erkannten Fehler beendet wurde.
Es beweist nicht zwingend, dass:
alle benötigten Daten enthalten sind,
das Archiv nicht beschädigt ist,
die Datenbank vollständig importiert werden kann,
die Zugangsdaten verfügbar sind,
die Website daraus startet.
Deshalb sollte eine Backup-Strategie gelegentliche Wiederherstellungstests enthalten.
Eine Testumgebung eignet sich hervorragend für Restore-Tests
Eine Sicherung muss nicht erst im Katastrophenfall ausprobiert werden.
Man kann sie auf einer separaten Testumgebung wiederherstellen.
Dabei lässt sich prüfen:
Startet WordPress?
Sind Beiträge vorhanden?
Funktioniert die Mediathek?
Sind Plugins und Theme vollständig?
Kann man sich anmelden?
Funktionieren wichtige Website-Funktionen?
Bei einem Shop könnten zusätzlich Testbestellungen und Kundenbereiche überprüft werden.
Damit wird aus einer theoretischen Sicherung ein überprüfter Wiederherstellungsweg.
Wie viele alte Backups sollte man behalten?
Nur die neueste Sicherung aufzubewahren kann riskant sein.
Angenommen, eine Website wird heute kompromittiert.
Der Angriff wurde aber bereits vor drei Wochen durchgeführt und erst jetzt entdeckt.
Wenn sämtliche älteren Backups inzwischen gelöscht wurden, kann auch die älteste verfügbare Sicherung bereits betroffen sein.
Deshalb ist Versionierung sinnvoll.
Man könnte beispielsweise unterschiedliche Aufbewahrungszeiträume kombinieren:
mehrere aktuelle Sicherungen
+
ältere Wochenstände
+
einige langfristige Monatsstände
Die genaue Anzahl hängt von Speicherplatz, Änderungsrate und Risiko ab.
Mehr Backups sind nicht automatisch besser
Auch Backup-Systeme können unnötig komplex werden.
Tausende unkontrollierte Sicherungsdateien beanspruchen Speicherplatz und erschweren die Suche nach dem richtigen Wiederherstellungspunkt.
Eine gute Retention-Strategie entscheidet deshalb bewusst, welche Sicherungen wie lange aufbewahrt werden.
Aktuelle Versionen werden meist dichter gespeichert.
Mit zunehmendem Alter können größere zeitliche Abstände genügen.
Backups müssen gegen unbefugten Zugriff geschützt werden
Eine WordPress-Sicherung kann hochsensible Informationen enthalten.
In der Datenbank können sich unter anderem Benutzerinformationen, Formulareinträge oder Kundendaten befinden.
wp-config.php enthält Zugangsinformationen zur Datenbank.
Ein öffentlich erreichbares Backup-Archiv wäre deshalb ein erhebliches Sicherheitsproblem.
Sicherungen sollten mindestens denselben Schutz erhalten wie die Produktivdaten – häufig sogar einen stärkeren.
Backup-Dateien gehören nicht ungeschützt ins Webverzeichnis
Eine Datei wie:
example.de/backup/wordpress-komplett.zip
ist keine gute Backup-Strategie, wenn sie öffentlich heruntergeladen werden kann.
Automatisierte Scanner suchen nach typischen Dateinamen und versehentlich veröffentlichten Sicherungen.
Backups sollten deshalb in dafür vorgesehenen Speicherbereichen liegen und nicht einfach innerhalb öffentlich erreichbarer Website-Verzeichnisse abgelegt werden.
Verschlüsselung kann bei externen Backups sinnvoll sein
Wer Sicherungen außerhalb der eigenen Infrastruktur speichert, sollte darüber nachdenken, welche Daten darin enthalten sind.
Bei sensiblen Daten kann Verschlüsselung eine zusätzliche Schutzebene darstellen.
Dann reicht der Zugriff auf das Speicherobjekt allein nicht aus, um den Inhalt unmittelbar zu lesen.
Dabei entsteht allerdings eine neue Verantwortung:
Der Schlüssel muss ebenfalls sicher und wieder auffindbar verwahrt werden.
Eine perfekt verschlüsselte Sicherung, deren Schlüssel verloren wurde, ist praktisch ebenfalls verloren.
Backups brauchen Monitoring
Automatisierung ist nur hilfreich, wenn Fehler bemerkt werden.
Ein Backup kann monatelang scheitern, weil:
der Speicher voll ist,
ein Passwort geändert wurde,
die Verbindung zum externen Speicher nicht mehr funktioniert,
ein Prozess abbricht,
ein Plugin deaktiviert wurde.
Deshalb sollte kontrolliert werden, ob Sicherungen weiterhin erfolgreich erzeugt werden.
Noch besser ist eine Warnung, wenn ein erwartetes Backup fehlt.
Das Alter der letzten Sicherung ist eine wichtige Kennzahl
Für eine Website könnte deshalb nicht nur interessant sein:
Backup vorhanden: ja/nein
sondern:
Wie alt ist die letzte erfolgreiche Sicherung?
Ein Shop mit einem Backup von gestern könnte bereits hunderte neue Bestellungen besitzen.
Bei einer statischen Unternehmenswebsite kann derselbe Zeitraum völlig unproblematisch sein.
Der zulässige Datenverlust bestimmt, wann ein Backup als zu alt gilt.
RPO beschreibt den tolerierbaren Datenverlust
In professionellen Backup-Konzepten wird dafür häufig das Recovery Point Objective, kurz RPO, verwendet.
Es beantwortet sinngemäß:
Wie weit dürfen wir im schlimmsten Fall in die Vergangenheit zurückfallen?
Ein RPO von 24 Stunden bedeutet, dass maximal ein Tag neuer Daten verloren gehen darf.
Ein Shop könnte dagegen ein deutlich kleineres RPO benötigen.
Man muss den Begriff nicht verwenden, um die Idee anzuwenden.
Die Frage nach dem akzeptablen Datenverlust ist für jede Backupplanung sinnvoll.
RTO beschreibt die tolerierbare Ausfallzeit
Eine zweite Frage lautet:
Wie schnell muss die Website wieder funktionieren?
Dafür wird häufig der Begriff Recovery Time Objective, kurz RTO, verwendet.
Für einen privaten Blog kann es vielleicht akzeptabel sein, wenn die Wiederherstellung einen Tag dauert.
Bei einem umsatzstarken Shop können bereits zwei Stunden kritisch sein.
Das beeinflusst auch die Backup-Technik.
Eine Sicherung, deren Wiederherstellung acht Stunden Handarbeit benötigt, kann für das eine Projekt völlig ausreichend und für ein anderes ungeeignet sein.
Eine gute Backup-Strategie beginnt also beim Geschäftszweck
Nicht bei der Software.
Nicht beim Plugin.
Nicht beim Speicheranbieter.
Sondern mit zwei Fragen:
Wie viele Daten dürfen verloren gehen?
Wie lange darf die Website ausfallen?
Erst danach lässt sich sinnvoll entscheiden, wie häufig gesichert wird und wie schnell eine Wiederherstellung funktionieren muss.
Kleine WordPress-Seiten brauchen trotzdem Backups
Ein privater Blog benötigt vielleicht kein Hochverfügbarkeitskonzept.
Aber auch dort steckt möglicherweise jahrelange Arbeit in Artikeln und Bildern.
Ein technischer Fehler kann wenige Sekunden dauern.
Die verlorene Arbeit könnte dagegen Monate oder Jahre repräsentieren.
Ein einfaches automatisiertes Backup auf einen unabhängigen Speicherort kostet wenig Aufwand und verhindert ein unverhältnismäßig großes Risiko.
Shops brauchen eine andere Strategie
Bei einem Shop verändert sich die Datenbank laufend.
Zwischen zwei Sicherungen können entstehen:
Bestellungen,
neue Kundenkonten,
Lageränderungen,
Zahlungsinformationen,
Produktänderungen.
Ein tägliches Backup könnte deshalb bereits zu grob sein.
Außerdem kann eine einfache Wiederherstellung der gesamten Datenbank problematisch werden, wenn dadurch zwischenzeitlich eingegangene Bestellungen verschwinden.
Für stark dynamische Systeme muss die Backup- und Recovery-Strategie deshalb wesentlich sorgfältiger geplant werden als für einen normalen Blog.
Auch Uploads können zeitkritisch sein
Eine Redaktion könnte innerhalb eines Tages dutzende neue Bilder hochladen.
Ein Fotograf könnte hunderte Dateien importieren.
Dann reicht es nicht, nur die Datenbank häufig zu sichern.
Auch neu hinzugekommene Dateien müssen berücksichtigt werden.
Backup-Frequenzen sollten also auf den tatsächlichen Änderungsmustern der Website beruhen.
Was passiert bei einem Serverumzug?
Eine vollständige WordPress-Sicherung ist gleichzeitig die Grundlage einer Migration.
WordPress beschreibt einen Umzug auf einen neuen Server grundsätzlich als Übertragung sowohl der Dateien als auch der Datenbank; ändern sich Datenbank-Zugangsdaten, muss die Konfiguration entsprechend angepasst werden. (WordPress Developer Resources)
Damit wird ein gutes Backup zu mehr als einem Notfallwerkzeug.
Es macht die Website portabel.
Wer seine Daten vollständig sichern und wiederherstellen kann, ist deutlich weniger von einem einzelnen Hostinganbieter abhängig.
Ein Backup schafft Unabhängigkeit
Das ist ein oft unterschätzter Vorteil.
Wenn eine Website ausschließlich über proprietäre Hoster-Werkzeuge gesichert werden kann, entsteht eine Abhängigkeit von diesem Anbieter.
Eine zusätzliche Sicherung, aus der sich WordPress auf einer anderen Infrastruktur wiederherstellen lässt, schafft dagegen echte Kontrolle über das Projekt.
Man besitzt nicht nur die Inhalte.
Man besitzt einen praktikablen Weg, sie anderswo wieder in Betrieb zu nehmen.
Was tun, wenn WordPress gehackt wurde?
Ein Backup kann bei der Wiederherstellung enorm helfen.
Aber einfach die neueste Sicherung zurückzuspielen reicht nicht zwangsläufig.
Zunächst muss geklärt werden, wann die Kompromittierung stattgefunden hat.
Ein drei Tage altes Backup kann bereits manipulierte Dateien enthalten.
Außerdem muss die Ursache behoben werden.
Sonst wird die frisch wiederhergestellte Website möglicherweise unmittelbar erneut kompromittiert.
Ein Backup stellt den Zustand wieder her.
Es beseitigt nicht automatisch die Schwachstelle, die zum Schaden geführt hat.
Deshalb sind ältere Sicherungen wertvoll
Bei einer versehentlich gelöschten Datei reicht meist die Sicherung von gestern.
Bei Sicherheitsvorfällen kann dagegen ein viel älterer Wiederherstellungspunkt benötigt werden.
Das ist ein weiterer Grund, nicht immer nur das letzte Backup aufzubewahren.
Historische Sicherungen schaffen Optionen.
Was tun bei einem fehlgeschlagenen Update?
Hier ist die Situation oft einfacher.
Wenn unmittelbar vor dem Update gesichert wurde und danach ein schwerer Fehler auftritt, ist der letzte funktionierende Zustand klar bekannt.
Je nach Art der Änderung kann man:
nur einzelne Dateien zurücksetzen,
das Plugin ersetzen,
die Datenbank wiederherstellen
oder die komplette Website zurückrollen.
WordPress empfiehlt vor Upgrades ausdrücklich die Sicherung der Datenbank und aller WordPress-Dateien. (WordPress Developer Resources)
Genau für solche Situationen lohnt sich diese Routine.
Ein vollständiges Restore ist nicht immer notwendig
Backups müssen nicht ausschließlich für Totalverluste verwendet werden.
Vielleicht wurde nur ein Bild gelöscht.
Vielleicht benötigt man eine alte Theme-Datei.
Vielleicht muss eine einzelne Datenbanktabelle rekonstruiert werden.
Eine gute Backup-Lösung erlaubt deshalb möglichst flexible Wiederherstellung.
Manchmal genügt eine Datei.
Manchmal braucht man die Datenbank.
Und manchmal muss tatsächlich die gesamte Website zurückgesetzt werden.
Versionierte Backups erleichtern kleine Reparaturen
Wenn mehrere Zeitstände verfügbar sind, kann gezielt nach einer älteren Version gesucht werden.
Das ist wesentlich eleganter, als wegen einer versehentlich gelöschten Datei die gesamte Website auf den Stand von gestern zurückzusetzen.
Denn ein kompletter Restore würde möglicherweise gleichzeitig neuere Änderungen überschreiben.
Backup und Restore sollten deshalb möglichst granular gedacht werden.
WordPress-Multisite braucht besondere Aufmerksamkeit
Bei WordPress Multisite teilen sich mehrere Websites Teile derselben WordPress-Installation und Datenbankstruktur.
Ein Backup betrifft dadurch möglicherweise nicht nur eine einzelne Website.
Die Wiederherstellung sollte entsprechend geplant und getestet werden.
Je komplexer die Installation, desto weniger sollte man darauf vertrauen, im Ernstfall improvisieren zu können.
Mehrere unabhängige WordPress-Seiten sollten getrennt wiederherstellbar sein
Wer viele Websites auf einem Server betreibt, sollte vermeiden, dass für die Wiederherstellung einer einzelnen kleinen Seite zwangsläufig der gesamte Server zurückgesetzt werden muss.
Ideal ist eine Struktur, in der jede Website eigene:
Dateien,
Datenbank,
Backup-Sätze
und Zugangsinformationen besitzt.
Dann kann ein einzelnes Projekt wiederhergestellt werden, ohne andere Websites zu beeinflussen.
Das ist nicht nur für Backups hilfreich, sondern auch für Sicherheit und Wartung.
Die Backup-Strategie sollte dokumentiert sein
Bei einer wichtigen Website sollte nicht nur eine Person wissen:
wo die Backups liegen,
wie man darauf zugreift,
welcher Zeitplan gilt,
wie wiederhergestellt wird.
Eine kurze Dokumentation kann im Ernstfall Stunden sparen.
Denn Störungen treten erstaunlich zuverlässig genau dann auf, wenn die Person, die „das damals eingerichtet hat“, gerade nicht verfügbar ist.
Ein praktisches Backup-Konzept für eine normale WordPress-Seite
Für einen gewöhnlichen Blog oder eine Unternehmenswebsite könnte ein sinnvolles Konzept beispielsweise so aussehen:
Produktive WordPress-Seite
↓ automatisch
regelmäßige Datenbank- und Dateisicherung
↓ zusätzlich
separater externer Speicherort
↓ mit
mehreren historischen Versionen
↓ regelmäßig
Wiederherstellung testen
Die konkrete Software ist dabei austauschbar.
Das Prinzip bleibt gleich.
Das perfekte Backup-System gibt es nicht
Ein extrem aufwendiges Backup-Konzept kann mehr kosten als die Website selbst.
Das wäre für einen kleinen Blog wenig sinnvoll.
Umgekehrt wäre eine einzige wöchentliche ZIP-Datei auf demselben Server für einen großen Onlineshop unzureichend.
Backup ist deshalb Risikomanagement.
Je wertvoller und dynamischer die Website ist, desto stärker sollte die Sicherung werden.
Was du dir über WordPress-Backups merken solltest
Ein vollständiges WordPress-Backup besteht normalerweise aus Datenbank und Dateien. WordPress dokumentiert diese beiden Bestandteile ausdrücklich als notwendig, um eine typische Website vollständig wiederherstellen zu können. (WordPress Developer Resources)
Eine zuverlässige Sicherung sollte außerdem:
automatisch und regelmäßig entstehen,
zum Änderungsrhythmus der Website passen,
nicht ausschließlich auf demselben System liegen,
mehrere Zeitstände aufbewahren,
vor größeren Änderungen verfügbar sein,
vor unbefugtem Zugriff geschützt werden
und vor allem tatsächlich wiederherstellbar sein.
Die wichtigste Backup-Regel lautet deshalb nicht:
„Mach Backups.“
Sondern:
„Sorge dafür, dass du einen bekannten funktionierenden Zustand in akzeptabler Zeit wiederherstellen kannst.“
Erst dann erfüllt ein Backup seinen eigentlichen Zweck.
Der nächste sinnvolle Schritt
WordPress ist nur ein konkreter Anwendungsfall eines größeren Themas.
In Was ein gutes Backup wirklich ausmacht schauen wir deshalb als Nächstes unabhängig von WordPress auf Versionierung, Aufbewahrung, Offsite-Sicherung, Redundanz, RPO, RTO und Wiederherstellung.
Danach können wir mit Warum Websites langsam werden in den Performance-Bereich wechseln und anschließend Caching einfach erklärt aufbauen.
Für WordPress selbst folgen später außerdem WordPress-Updates richtig durchführen, WordPress-Staging verstehen und WordPress-Sicherheit.