Backup-Strategien für WordPress Entwickler

#cli #diskussion #wordpress

Backups mit WP-CLI auf dem eigenen Server

Wer eine eigene WordPress Seite betreibt, sollte stets auch ein aktuelles Backup parat haben, denn es kann immer etwas schief gehen, wie Stefan Kremer in seinem Blogpost zum Auftakt des Backup-Themenmonats deutlich aufgezeigt hat.

Obwohl wir mit Plugins wie BackWPup von Inpsyde oder dem kostenpflichtigen Backup-Dienst VaultPress von Automattic sehr gute Erfahrungen gemacht haben, ist gerade auch der Zeitraum der Entwicklung einer neuen Seite besonders kritisch.
In einem so frühen Entwicklungsstadium eines neuen Projekts wurde die eigene Backup-Strategie eventuell noch nicht festgelegt und/oder es mangelt noch an der entsprechenden Konfiguration der Plugins oder des Backup-Servers.

Entwicklung mit Git

Für die lokale Entwicklung verlassen wir uns auf die Versionskontrolle mit Git, die es uns ermöglicht, alle Änderungen am Quellcode zu dokumentieren und zu versionieren. Auch Git bietet die Möglichkeit mit git archive -o backup.zip HEAD ein Archiv zu erstellen, doch was, wenn es nicht nur Änderungen am Code, sondern auch in der Datenbank gab? Und was, wenn nicht alle Dateien versioniert sind?

Um es mit den Worten von Stefan Kremer zu sagen:

Gut wer jetzt ein Backup hat…

…und dieses Backup auch wieder herstellen kann.

In diesem Fall (und vielen weiteren) ist es hilfreich, stets auf richtige Backups mit allen Daten zugreifen zu können.

 

Backup der Datenbank

Um die WordPress-Installation vollständig zurücksetzen zu können, sichert man die komplette WordPress-Datenbank. Ein vollständiger Export hat zudem den Vorteil, dass dieser ebenso für die Migration einer Seite verwendet werden kann.

Die Datenbank kann dafür entweder manuell (z.B. mit phpMyAdmin) oder direkt über das CLI von MySQL exportiert werden. Nutzer von WP-CLI (WordPress Command Line Interface) können stattdessen den Befehl wp db export nutzen.

Um den Überblick nicht zu verlieren, empfiehlt es sich, jeden Export mit dem aktuellen Datum zu versehen.
Ein typischer Befehl für den gezippten Export per WP-CLI im Format name-datum.sql.gz könnte demnach folgendermaßen aussehen:

wp db export - | gzip > ./db_backup-$(date +%Y-%m-%d-%H%M%S).sql.gz

 

Backup der Dateien

Neben der Datenbank werden auch alle für das Projekt relevanten Dateien benötigt. Was relevant ist und was nicht muss von Fall zu Fall entschieden werden; wer beispielsweise die vollständige Migration einer Seite plant, kann direkt die komplette WordPress-Installation archivieren. Auch hier hilft es, das neu erstellte Archiv gleich mit dem aktuellen Datum zu versehen:

tar --create --gzip --verbose --absolute-names --file=./wp_backup-$(date +%Y-%m-%d-%H%M%S).tar.gz --exclude=*.tar.gz /var/www/websites/wp
  • tar Befehl zum Erstellen des Archivs
    • --create Erstellt ein neues Archiv
    • --gzip Komprimiert das Archiv mit Gzip
    • --verbose Loggt die zum Archiv hinzugefügten Dateien
    • --absolute-names Berücksichtigt den / zu Beginn von Dateinamen
    • --file Legt Pfad & Name der zu erstellenden Datei fest
    • --exclude Schließt diese Dateien oder auch Dateitypen vom Archiv aus
    • Am Ende wird noch der Pfad zum Projektordner angegeben, der archiviert werden soll.

 

Backups automatisieren

Das Erstellen der Backups kann beispielsweise mit einem Cronjob automatisiert werden. Dafür hinterlegt man die beiden Befehle in einem Bash-Skript, welches anschließend in den definierten Intervallen über den Cron aufgerufen und ausgeführt wird. Die Pfade sollten dabei absolut und mit dem Zusatz --path angegeben werden, um von einem beliebigen (nicht öffentlichen) Verzeichnis auf dem Server aufgerufen werden zu können:

#!/bin/sh
/usr/local/bin/wp db --path=/var/www/websites/wp - | gzip > /var/www/backups/db_backup-$(date +%Y-%m-%d-%H%M%S).sql.gz &
tar --create --gzip --absolute-names --file=/var/www/backups/wp_backup-$(date +%Y-%m-%d-%H%M%S).tar.gz --exclude=*.tar.gz /var/www/websites/wp

Das Skript gibt es zum Kopieren auch als Gist.

 

Cronjob anlegen

Im nächsten Schritt muss das obige Bash-Skript mit dem Namen backup.sh noch über den Cron aufgerufen werden.
Statt WP Cron, also den internen Cronjobs von WordPress, ist es schneller und zuverlässiger einen echten Cronjob direkt im System zu hinterlegen.

Über crontab -e kann der neue Cronjob mit dem gewünschten Intervall (z.B. täglich um 18:30 Uhr) eingetragen werden:

30 18 * * * sh /var/www/backups/backup.sh > /var/www/logs/cronlog 2>&1

Der Zusatz 2>&1 loggt eventuelle Fehler in einem eigenen Logfile unter /var/www/logs/cronlog, was die erste Anlaufstelle bei eventuellen Problemen sein sollte.

Weiterführende Links für individuelle Zeitintervalle:

 

Backups verwalten

Einmal exportierte Inhalte und Archive sollten auf keinen Fall öffentlich einsehbar sein und vom Server entfernt werden, sobald diese nicht mehr benötigt werden.

Die oben beschriebene Methode stellt zudem keine Dauerlösung dar, da die Backups immer off-site, also auf einem anderen Server abgelegt werden sollten. Ansonsten besteht die Gefahr, dass bei einem Datenverlust auch das Backup beschädigt oder sogar verloren ist.

Als Dauerlösung ist also ein Backup-Server in Kombination mit BackWPup oder das Angebot eines externen Dienstleisters wie VaultPress deutlich besser geeignet.

 

Schlusswort

Eine aktuelle und vollständige Sicherheitskopie der eigenen Website parat zu haben, sollte eigentlich selbstverständlich sein. So selbstverständlich, dass dem Thema in der Praxis nicht immer genug Aufmerksamkeit geschenkt wird.
Um dieses durchaus umfangreiche Thema wieder mehr in den Fokus zu rücken, hat Simon Kraft den Oktober zum Backup-Themenmonat ernannt, denn neben der reinen Datensicherung gilt es, Sicherheitsaspekte und die Wiederherstellungsstrategie anhand der gesicherten Daten zu bedenken und auch zu prüfen.

WP Letter

Mehr zum Thema Backups mit WordPress und viele weitere wichtige Themen rund um WordPress gibt’s im WordPress-Newsletter.

 

Ihr Kommentar