Backups in WordPress: Ein kurzer Überblick

Ich habe diese Woche drei Websites repariert, nachdem diese gehackt worden sind. In allen drei Fällen hatten die Kunden gar kein oder nur ein sehr veraltetes Backup. Das macht den Aufwand für die Reparatur deutlich größer. Mit einem aktuellen Backup wäre der Schaden recht schnell behoben. Ich nehme das zum Anlass, einen kleinen Grundlagenartikel zum Thema zu erstellen.

Nichts ist so wichtig wie regelmäßige Backups. Das gilt für die Daten auf dem eigenen Computer genauso wie für die Website. Egal wie diese erstellt wurde, egal welches Redaktionssystem.

Ein Export reicht nicht aus

Immer wieder erlebe ich es, dass Website-Administratoren die Import/Export-Funktion von WordPress aus Unwissenheit nutzen und glauben, damit ein aktuelles Backup zu haben. Der XML-Export reicht aber bei weitem nicht aus, um bei Problemen die Seite vollständig wiederherstellen zu können. Er ist im Prinzip nur eine Ansammlung der Seiten- und Beitragsinhalte, ohne Plugins, Themes und deren Daten. Deswegen muss ein „echtes“ Backup her…

Der XML-Export von WordPress ist kein Ersatz für ein „echtes“ Backup mit allen Dateien und der Datenbank.

Ein „echtes“ Backup

Ein solches „echtes“ Backup besteht aus allen Dateien der Installation, also allen Theme- und Plugin-Dateien sowie dem Inhalt des uploads-Ordners, der alle hochgeladenen Dateien (insbesondere Mediendateien wie Bilder) enthält. Aber auch diese Dateien alleine machen noch keine komplette WordPress-Installation, denn es fehlen immer noch jegliche Konfigurationen und (ganz wichtig) die Inhalte. Diese Daten liegen in der Datenbank vor, weswegen ein ordentliches Backup sowohl alle Dateien als auch einen Export („Dump“) der Datenbank enthalten sollte.

Backup-Größe macht Schwierigkeiten

Ich habe schon alle Backupgrößen zwischen 10 MB und 5GB gesehen. Ja, auch 5GB sind nicht unbedingt ungewöhnlich. Mein größtes Website-Backup (für eine Seite) war 18GB groß.

Logischerweise entsteht dies meist durch sehr viele Fotos in sehr vielen unterschiedlichen Größen. Wenn dann das Backup eine solche Größe annimmt, kommen kleine und kostengünstige Hostingpakete schon mal an ihre Grenzen:

  • die Server-Performance ist zu schwach, um das Backup zu erzeugen. Die maximale CPU-Zeit für Scripte wird erreicht oder das Speicherlimit von PHP
  • manche Hoster begrenzen die Größe von per Script erzeugten Dateien
  • manche Backup-Plugins verschlucken sich bei so großen Backups
  • das Speichern mehrerer älterer Backups macht den Festplattenplatz im Hostingpaket voll

Leider gibt es zur Lösung dieser Probleme kein Allheilmittel. Bei Problemen mit dem Plugin lohnt es sich gegebenenfalls ein anderes Plugin zu testen. Mit BackWPup (siehe unten) komme ich auch auf schwierigen Hosterumgebungen ganz gut zu recht.

Ist die Server-Performance zu begrenzt, hilft je nachdem nur ein Upgrade oder ein Hosterwechsel. Wer eine besonders große Website sein Eigen nennt, muss dafür auch eine entsprechende Umgebung zur Verfügung stellen.

Unter Umständen hilft es ja bereits schon, Bilder nicht von der Digitalkamera direkt ohne Nachbearbeitung in 12MB Größe hochzuladen, sondern die Fotos per Bildbearbeitung auf eine erträgliche Größe zu bringen. Mehr als 2000px Breite bauchen die Bilder wirklich nur in den seltensten Fällen. So kann man viele Megabyte oder Gigabyte Daten sparen.

Wie wird ein Backup erstellt?

Möglichkeit 1: beim Hoster

Das Backup muss nicht in WordPress selbst erzeugt werden, sondern kann, je nach Hoster und Tarif, im Vertrag beinhaltet sein und automatisch vom Hoster durchgeführt werden. Dabei sollte man jedoch auf Folgendes achten:

  • das Backup sollte Dateien und Datenbank umfassen
  • es sollten Backups zumindest der letzten zwei Wochen verfügbar sein, unabhängig vom Backup-Intervall (siehe unten)
  • es sollte möglich sein, die Backup-Daten auch herunterzuladen

Manche Hoster bieten ein eigenes Wiederherstellungsverfahren an, bei dem man ein Backup automatisch wieder einspielen kann. Das ist in manchen Fällen sinnvoll, jedoch sollte es zusätzlich möglich sein, das Backup herunterzuladen, zum Beispiel um eine Kopie des Systems für Testzwecke anlegen zu können.

Zusätzlich sollte man darauf achten, dass die Wiederherstellung des Systems keine Zusatzkosten verursacht, sondern mit einem einfachen Klick möglich ist. Sollte man aus einem Backup nur einzelne Dateien oder einzelne Datenbank-Tabellen wiederherstellen wollen, so ist jedoch Zusatzaufwand beim Hoster meist unumgänglich.

Möglichkeit 2: auf dem Server

Wer einen eigenen Server betreibt oder zumindest SSH-Zugriff auf seinen Server beim Hoster hat (meist nur bei teureren Paketen möglich), der kann das Backup auch selbst steuern ohne dafür WordPress zu benutzen. Man kann mit einem Script recht einfach einen Datenbankexport erzeugen und auch alle vorliegenden Dateien in ein Archiv packen.

Als Alternative bietet sich wp-cli an, das Kommandozeilen-Tool von WordPress. Dieses muss zusätzlich installiert werden, bietet dann aber einige Möglichkeiten, zum Beispiel auch zur Scriptsteuerung von Backup-Plugins.

Die Beschreibung der Details würde hier den Rahmen des Artikels sprengen. Vielleicht werde ich das mal einzeln in einem gesonderten Beitrag beleuchten.

Möglichkeit 3: mit einem Backup-Plugin

Für die meisten einfachen Websites wird der Weg vermutlich über ein Backup-Plugin in WordPress gehen. Dieser Weg ist einfach eingerichtet und ermöglicht es auch technisch unerfahrenen Nutzern, schnell Backups zu erzeugen.

Die Auswahl an Backup-Plugins ist riesig. Hier hat auch jeder seine eigenen Vorlieben. Ich persönlich nutze immer BackWPup, welches sich auch in schwierigen Hosting-Situation als recht stabil erwiesen hat.

Möglichkeit 4: mit einem externen Dienst(leister)

Eine weitere Möglichkeit besteht darin,  die Daten direkt mit einem Cloud-Dienst zu sichern. In der Regel benötigen diese ebenso ein installiertes Plugin in der WordPress-Installation, um mit der Seite kommunizieren zu können. Insofern ist dies eigentlich nur Möglichkeit 3b 😉

Auch hier können die gleichen Performance-Probleme auftreten wie  mit „normalen“ Backup-Plugins. Der Vorteil dieser Lösung ist jedoch, dass die Daten direkt in der Cloud vorliegen (siehe Punkt „Speicherung auf externe Server“).

Bekannte Beispiele sind BlogVault oder allgemeine Verwaltungsdienste wie ManageWP oder InfinteWP. InfinteWP ist mein Favorit, denn diese Software kann man auf eigene Server installieren. man ist dann trotz externem Backup-Dienst nicht auf eine Speicherung auf einem ausländischen Server angewiesen.

Zu guter Letzt gibt es natürlich auch Dienstleister, die sich um die Erstellung der Backups kümmern, so dass man als Website-Betreiber sich um nichts mehr kümmern muss. Wer Interesse hat, darf sich gerne bei mir melden. 😉

 Wie häufig mache ich ein Backup?

Die Frage, wie häufig ein Backup notwendig ist, hängt auch von der Menge an Inhalten ab, die neu erstellt werden. Werden nur selten Inhalte erstellt oder geändert, muss das Backup auch nicht so häufig erstellt werden wie auf Websites, die täglich einige Beiträge veröffentlichen.

Generell rate ich zu mindestens wöchentlichen Backups. Selbst wenn sich in dieser Zeit keine Inhalte ändern, gibt es doch üblicherweise das eine oder andere Plugin oder Theme, welches ein Update benötigt. Mit einem wöchentlichen Backup bleibt man immer ausreichend aktuell und kann auf jede Unwägbarkeit reagieren.

Weiterhin rate ich dazu, möglichst 10 oder 15 alte Backups vorzuhalten, um zu verschiedenen Backup-Zeitpunkten zurückspringen zu können. Die mögliche Anzahl ist natürlich abhängig vom Backup-Intervall und dem zur Verfügung stehenden Platz. Bei einem täglichen Backup einer Seite mit 3GB ist das Verwahren von Backups der letzten 4 Wochen schwieriger als bei einer kleinen Seite mit 50MB und wöchentlicher Sicherung.

Übrigens: das Backup sollte voll automatisch ablaufen. Manuelle Backups kann man vor bestimmten Arbeiten zusätzlich machen (vor Updates oder z.B. vor der Umstellung auf SSL). Das regelmäßige Backup sollte aber ohne eigenes Zutun erfolgen. Die Plugins bieten dazu im Regelfall Einstellungsmöglichkeiten und auch die Hoster-Backups sind automatisiert. Das eigene Backup-Script auf dem Server läuft am besten als Cronjob.

Wohin mit dem Backup?

Nun ist es nicht damit getan, ein regelmäßiges Backup der eigenen Seite zu erstellen. Das Backup sollte auch immer im Zugriff sein. Deswegen ist es nicht ratsam, dass Backup (ausschließlich) auf dem eigenen Server in einem Verzeichnis der WordPress-Installation liegen zu lassen. In folgenden Fällen wäre das genauso gut wie gar kein Backup zu haben:

  • der Hoster hat ein Problem und die Seite ist weg. Dann ist auch das Backup (erstmal) weg.
  • es gibt Ärger mit dem Hoster und man möchte den Hoster wechseln
  • die Seite wurde gehackt. Liegt das Backup auf dem gleichen Server, muss man davon ausgehen, dass das Backup auch vom Hacker manipuliert sein könnte.  Da man es zumindest nicht ausschließen kann, darf man ein solches Backup nicht verwenden, um den Schaden zu reparieren

Das Backup sollte deswegen in einer externen Quelle liegen. Welche das ist, kann sehr unterschiedlich sein:

  • ein anderer Server, per FTP angebunden an den Website-Server
  • der eigene PC, wenn man die Backups manuell herunterlädt. Ein Zusenden via E-Mail ist in den meisten Fällen übrigens nicht ratsam, da die Backup-Größe in der Regel die maximale Größe der E-Mails überschreitet.
  • ein Cloud-Dienst wie Dropbox oder Google Drive. Ggf. aus Datenschutzsicht ein Problem.
  • die eigene Cloud, also Owncloud oder Nextcloud
  • ein Cloudspeicher-Anbieter, also etwa Amazon S3 oder Microsoft Azure

Ein Problem dabei ist, dass sich das Backup-Plugin mit dem jeweiligen anderen Server verbinden muss und dafür Zugangsdaten benötigt. Diese sollte man aber eigentlich nicht im Plugin hinterlegen, denn ein erfolgreicher Angreifer könnte diese Daten auslesen und auch nutzen. Deswegen sollten wenn möglich keine Zugangsdaten (also Benutzername und Passwörter) gespeichert werden, sondern maximal API-Schlüssel für den programmatischen Zugriff. Diese können bei Missbrauch gesperrt werden und sind nicht so leicht an anderer Stelle wiederverwendbar.

Schon mal an die Wiederherstellung gedacht?

Toll, wir haben ein Backup! Schon mal überprüft, ob das Backup auch in Ordnung ist und eine Wiederherstellung ohne Weiteres möglich ist?

Was hilft das beste Backup, wenn die Wiederherstellung nicht funktioniert oder das Vorgehen dafür unbekannt ist? Was, wenn der Upload eines Backups 3 Stunden dauert, selbst wenn man nur eine Datei auswechseln will?

Bei allen Backup-Methoden sollte man sich ebenso im Klaren sein, wie eine eventuelle Wiederherstellung abläuft. Das gilt sowohl für eine vollständige Wiederherstellung des gesamten Backups, als auch für die Wiederherstellung einzelner Dateien/Verzeichnisse oder einzelner Datenbank-Tabellen.

Der Fachbegriff für all diese Überlegungen ist übrigens „Disaster Management“. Und jeder sollte eine Strategie auf Lager haben, was er/sie im Falle eines Falles zu tun hat. Dazu gehört auch, die einzelnen Abläufe schon mal geprobt zu haben und auch regelmäßig immer wieder auszutesten. Mit dieser Übung klappt die Wiederherstellung im Ernstfall dann umso schneller und besser.

Fazit

Mein kurzer Überblick war gar nicht so kurz, denn das Thema gibt viel her. Trotzdem habe ich diverse Teilbereiche nur kurz angeschnitten. Hier gibt es also noch Bedarf an Vertiefung in späteren Beiträgen.

Backups sind unverzichtbarer Teil der eigenen Website. Dabei gibt es sehr unterschiedliche Methoden wie diese Backups erstellt werden können. Die Wahl der Methode ist unerheblich, jedoch ist es wichtig, das Backup auf externe Server zu speichern. Backups sollten mindestens wöchentlich erstellt werden. Zur Vermeidung von Performance-Problemen sollten die Daten so optimiert sein, dass nicht unnötige Datenmengen erzeugt werden. 10 bis 15 Backups sollte man immer parat haben, abhängig jedoch auch vom Backup-Intervall.

Gerne beleuchte ich Teilbereiche dieses Themas in Zukunft genauer und freue mich auf Feedback dazu, welcher Teil am ehesten einen eigenen Beitrag bedarf. freue mich auf Kommentare!


Über Marc Nilius

Diplom-Informatiker, 20 Jahre IT- und Web-Erfahrung, 5 Jahre intensive WordPress-Erfahrung, Mit-Organisator WordPress Meetup Köln und WordCamp Köln 2016, Wapuu-Fan

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.