Es gibt verschiedene Möglichkeiten ein Backup von WordPress zu erstellen, je nach dem wie viel Vorwissen und Nutzerrechte vorhanden sind. In diesem Post möchte ich einige Möglichkeiten durchgehen. Dazu müssen wir wissen, was wir überhaupt sichern müssen und wie wir dies tun können. Aktuell habe ich ein automatisiertes Backup Skript auf dem Pi laufen, welches ich auch in das repository eingefügt habe. Zugegebenermaßen ist es etwas lang, allerdings erfüllt es sehr gut seinen Zweck. Mit diesem Post möchte ich grundlegende Ideen erklären, die möglicherweise hilfreich für euer eigenes Backup Skript sein könnten.
0. Backup Optionen
Prinzipiell gibt es viele verschiedene Backup optinen um die aktuellen WordPress Daten zu speichern.
Um alle Posts und Meta Informationen zu speichern kann beispielsweise die WordPress integrierte Backup Funktionalität genutzt werden unter Werkzeuge > export, wodurch XML Dateien erstellt werden. Allerdings hatte ich bei der Wiederherstellung einige Probleme mit dem Upload, da die Datei zu groß war. Dies könnte man umgehen, indem die maximale Upload größe erhöht wird, oder der Backup in mehrere Teile zerlegt wird. Da wir jedoch vollen Zugriff auf unseren Server haben gibt es durchaus bessere Backup methoden.
Eine sehr triviale Methode des backups wäre es, den gesamten WordPress Ordner inklusiver Datenbank zu kopieren und woanderse (auf einer externen HDD) abzulegen. Eine Wiederherstellung würde einfach über Kopieren und Ersetzen funktionieren. In meinem Fall wollte ich jedoch die Daten zusätzlich in der cloud ablegen. Der WordPress Ordner ist jedoch 400mb+ groß, was etwas unhandlich ist, wenn man diesen jeden Tag hochladen muss.
Es ist daher sinnvoll, nur die notwendigen Daten zu sichern. Doch was sind “notwendige” Daten? Im Folgendem möchte ich gerne meinen ANsatz näher erläutern.
1. WordPress Komponenten
Zu erst sollten wir uns im Klarem sein, was wir sichern müssen. In #0 Einführung in Docker und WordPress haben wir bereits die wichtigen WordPress Komponenten ermittelt. Diese bleiben bestehen unabhängig davon, ob wir eine normale WordPress Installation oder dies durch Docker vornehmen.
- unsere Datenbank
- plugins
- hochgeladene Dateien (Bilder, Videos)
- Konfigurationsdateien (Caddyfile, wp-config.php)
2. Datenbank Backup
Ein Datenbank Abzug lässt sich über ein mysql dump initiieren. Dieser Befehl generiert ein SQL DDL Datei, welcher bei Ausführung unsere Datenbankstrukturen sowie darin enthaltene Daten erstellt. Diese Funktionalität befindet sich bei einer normalen Installation unter /usr/bin/mysqldumb. Diesen müssen wir nun aus unserem Docker Container aus aufrufen.
Zuerst müssen wir also den Container herausfinden:
$ mysql_container=$(docker ps | sed 's/ */|/g' | cut -d '|' -f7 | grep webservice_mariadb)
Dann rufen wir den mysqldump Befehl auf und leiten die Ausgabe auf unser host System um. Im Folgendem Code Snippet werden die Authentifizierungsdaten aus der gleichen Konfigurationsdatei gelesen, wie sie für die Instantiierung der MariaDB genutzt wurden. Der Name der Datei beinhaltet auch noch ein Datumspräfix um einzelne Abzugsversionen voneinander zu unterscheiden.
$ docker exec $mysql_container /usr/bin/mysqldump --user="${mysql_user}" --password="${mysql_pwd}" --all-databases > $sql_backupfilename
Um die Datenbank wiederherzustellen, kopieren wir den dump nach /data/restore, welches automatisch in den Kontainer gemountet wird. Dann führen wir das SQL innerhalb des Kontainers aus. Hier muss beachtet werden, dass der dump auch existierende Tabellen droppt, sodass dies wirklich nur ausgeführt werden sollte, wenn ihr euch sicher seid.
$ docker exec -it <container-ID> sh
$ cd restore
$ mysql -u root -p < backup_dumb.sql
3. Backup von plugins
Plugins speichern zwar ihre Meta Daten in der Datenbank ab, allerdings ist es möglich, dass durch Versionssprünge Kompatibilität nicht immer gewährt werden kann, sodass es sicherer ist, neben der aktuellen Datenbank auch die zu dem Zeitpunkt genutzten plugin Versionen zu sichern. Die plugins sind meist unter /data/wp/www/wp-content/uploads/plugins abgespeichert, allerdings ist es möglich, dass sie auch noch andere Daten woanders abgelegt haben (z.B. unter uploads). Um den Backup Prozess zu vereinfachen, gehe ich davon aus, dass wir nur den plugins Ordner sichern müssen und habe dies mit folgendem Befehl bewerkstelligt:
$ rsync -a --delete $source_plugin_dir backup/
- Das -a flag signalisiert rsync, dass es rekursiv arbeiten und Meta Informatione beibehalten soll (ausgenommen sind hard links)
- Das –delete flag signalisiert rsync Dateien im Zielordner zu überschreiben oder zu löschen , wenn diese nicht mehr existieren
(Quelle: siehe man, stackoverflow or howtogeek.com )
4. Bilder und andere Uploads sichern
Sobald ich Posts erstellt und Bilder hochgeladen habe, werden diese nicht mehr gelöscht oder geändert. Es macht daher Sinn nicht den gesamten Ordner zu sichern, wie es bei den Plugins der Fall war, sondern nur neue Bilder die noch nicht gesichert wurden. Eine Art Delta Ermittlung ist daher sinnvoll.
Wichtig für diesen Prozess war es für mich, dass die Bilder in einer Jahr/Monat Ordnerstruktur abgelegt werden. Dies kann eingestellt werden unter Einstellungen > Medien > Organisiere Uploads in Monat-Jahr basierende Ordner. Die Delta Ermittlung erfolgt im groben wie folgt:
- Für jeden Monat führe Folgendes aus:
- Wenn ein SUCCESS flag existiert, überspringe den Ordner, ansonsten führe fort
- Sicherung mittels rsync erstellen und zippen
- Generiere einen hash über die gezippte Datei, speicher ihn ab und vergleiche ihn mit dem vorherigem hash um Änderungen zu detektieren. Wenn Änderungen vorhanden sind, lade die zip Datei hoch
- Wenn der Monat (und das Jahr) des gerade bearbeitenden Ordners kleiner als der aktuelle Jahr/Monat ist, schließe den Ordner ab indem ein SUCCESS flag erstellt wird
5. Abschließende Bemerkungen
Wichtig ist natürlich auch die Sicherung der Konfigurationsdateien, die wir noch nicht behandelt haben. Da dies meist eine einmalige Sache ist, habe ich dafür keinen extra Prozess erstellt. Folgende Dateien sind noch manuell zu sichern:
- Caddyfile (von unserem Webserver um entsprechendes Routing zu sichern)
- mysql_credentials Datei und wp-config.php Datei (um die gleiche Datenbank Verbindungseisntellungen nach einer WIederherstellung beizubehalten)
Ich nutze für das Hochladen meiner Backup Dateien in Dropboxeinen Dropbox-loader container (https://github.com/andreafabrizi/Dropbox-Uploader). Dieser muss zuerst initialisiert und die erzeugte Konfigurationsdatei abgespeichert werden. Danach kann der Dropbox-loader automatisiert aufgerufen werden, ohne Authentifizierungsdateien angeben zu müssen.
Da bei jedem Backup Vorgang ein Vollabzug der Datenbank erstellt wird, sollte auch daran gedacht werden, entsprechend alte mysql dumps zu entfernen.
Es ist auch möglich mehrere WordPress Instanzen zu sichern, je nachdem wie diese erstellt wurden. Ich betreibe zusätzlich noch eine Subdomain auf einer separaten WordPress Installation, die jedoch die gleiche Datenbank nutzt. Somit muss ich also nur ein mal die Datenbank , jedoch natürlich separat die Bilder und Plugins sichern.
Ich habe mein Backup Skript im Repository im Ordner backup abgelegt sowie eine Beispiel Konfigurationsdatei beigefügt. Wenn ihr beispielsweise die Dateien nicht auf dropbox hochladen wollt, müsstet ihr nur den entsprechenden Codeblock anpassen.
Es hat mir sehr viel Spaß gemacht ein solches Skript zu erstellen, tatsächlich denke ich, dass die Nachfrage eines solchen allumfassenden Backup Shell Skriptes jedoch nicht ganz so hoch ist, weshalb es nicht vollständig optimiert und dokumentiert ist. Falls ihr über diesen Beitrag stolpern solltet und tatsächlich solch ein Projekt in Angriff nehmen wollt, könnt ihr ruhig auf diesen Beitrag antworten und ich versuche meine bestes euch zu unterstützen 🙂
