Automatisiertes WordPress Backup – Hands On

Es gibt sicher eine Vielzahl von Plugins, Erweiterungen, für WordPress, auch um ein Backup zu erstellen. Jedes Plugin aber bringt zusätzliches Angriffspotential mit sich. Eigentlich ist die Bezeichnung Potential nicht weitreichend genug, vielmehr gibt es verschiedene Angriffsvektoren, die auf verschiedene Angriffsflächen wirken können. Von der mangelhaften Wartung und Testung, bis hin zum Ende der Unterstützung für dieses Plugin gibt es viele Auslöser. Deswegen habe ich mich entschlossen meine WordPress Installationen mit Bordmitteln des Betriebssystems zu sichern und auf die Verwendung von Plugins so weit als möglich zu verzichten.

Back up der Datenbank

WordPress verwendet in der Regel eine MySQL oder MariaDB als Datenbank. MariaDB wurde von MySQL Entwicklern, die bei Oracle arbeiten, abgespalten (vgl.: Vergleich und geschichtliche Entwicklung). SQL (vgl.: structured query language) Befehle sind auf beiden Datenbank Management Systemen verwendbar und ident.

stefan@web:~ $ mysql --version

mysql  Ver 15.1 Distrib 10.3.22-MariaDB, for debian-linux-gnueabihf (armv8l) using readline 5.2

Auf diesem System läuft eine MariaDB Version 10.3.22. Jetzt schauen wir mal, was für Datenbanken überhaupt da sind und wie unsere WordPress Datenbank heisst.

stefan@web:~ $ mysql -u root -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 9149
Server version: 10.3.22-MariaDB-0+deb10u1 Raspbian 10

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| wordpress          |
+--------------------+
4 rows in set (0.001 sec)

MariaDB [(none)]> 

Die Datenbank, die wir sichern wollen, heisst in diesem Fall ‚wordpress‘. Mit „\q“ verlassen wir die Eingabeaufforderung wieder und sind auf der Konsole zurück.

stefan@web:~ $ mysqldump -u root -p wordpress > wordpress.sql

Mit ‚mysqldump‘ fertigen wir eine konsistente Kopie der WordPress Datenbank im laufenden Betrieb an. Die Option „-u“ ist der Benutzerkontext mit dem dieser Befehl ausgeführt wird. Die Option „-p“ fordert interaktiv zur Eingabe des Passworts auf. ACHTUNG: „wordpress“ ist nicht das Passwort, sondern die Datenbank, die abgezogen wird. Die Ausgabe wird in ein Datei umgelenkt mit dem Namen „wordpress.sql“. Diese Datei kann man sich auch anschauen mit dem Befehl cat zum Beispiel und ist auch bearbeitbar. Das ist zum Beispiel bei der Migration von Vorteil – hier können alle Parameter schnell korrigiert und ersetzt werden, wie Hostnamen, Links, etc…

stefan@web:~ $ sudo vi /etc/mysql/mariadb.conf.d/50-server.cnf 
...
<snip>
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id              = 1
log_bin                = /var/log/mysql/mysql-bin.log
expire_logs_days        = 3
#max_binlog_size        = 100M
#binlog_do_db           = include_database_name
#binlog_ignore_db       = exclude_database_name
<snip>
...

Sie sollten auch noch vorher kontrollieren, ob die Transaktionsprotokollierung aktiviert ist. Nur so kann die Datenbankengine die Datenbank konsistent halten, während sie im laufenden Betrieb rausgeschrieben wird. Das wird durch den Eintrag „log_bin“ erreicht.

Back Up der Dateien

Mit Dateien sind in diesem Fall Vorlagen, Bilder, Programmcode, Plugins (vgl.: templates, plugins etc..) gemeint. Im konkreten Fall ist das Basisverzeichnis der WordPress Seite im Verzeichnis /var/www/html. Das hängt aber im Regelfall von der Konfiguration des Webservers ab.

stefan@web:~ $ sudo tar -cpvzf wordpress.tar.gz /var/www/html/

Mit diesem Kommando wird ein komprimiertes Archiv, dass auch die Benutzerberechtigungen mitführt, erstellt. Die Archivdatei findet sich dann in dem Verzeichnis, in dem dieser Befehl ausgeführt wird, wieder.

Wiederherstellen von WordPress am selben Server

Wiederherstellen der Datenbank

Ein Update ging schief, die Seite wurde kompromittiert, oder auch nur Zurücksteigen auf einen historischen Stand der Webseite  setzt voraus, dass die Datenbankinhalte zu diesem Zeitpunkt wiederhergestellt werden.

stefan@web:~ $ mysql -u root -p wordpress < wordpress.sql

Mit diesem Befehl wird die Datenbank „wordpress“ durch die archivierte Datenbank, „wordpress.sql“, ersetzt.

stefan@web:~ $ tar -xvzf wordpress.tar.gz

Entpackt im aktuellen Verzeichnis die Archivdatei „wordpress.tar.gz“. Dazu muss die Datei natürlich auch vorher vorhanden sein.

sudo cp -R var/www/html/* /var/www/html/

Alle Dateien aus dem aktuellen Vereichnnis ~/var/www/html, inklusive aller Unterzeichnisse, werden in das Basisverzeichnis der Webseite kopiert.

Backup via Mail versenden

Der gute alte Mutt als Mail User Agent (vgl. MUA) kommt hier zum Einsatz. Gmail wird als externer Mailserver zum Senden verwendet. Die Konfiguration von Mutt (vgl.: .muttrc im Benutzerverzeichnis) sieht so ähnlich aus.

stefan@web:~ $ cat .muttrc
set realname = "WP Back Up"
set from = "wpbackup@gmail.com"
set use_from = yes
set envelope_from = yes

set smtp_url = "smtp://wpbackup@smtp.gmail.com:587/"
set smtp_pass = "ANWENDUNGSPASSWORT"
set imap_user = "wpbackup@gmail.com"
set imap_pass = "ANWENDUNGSPASSWORT"
set folder = "imaps://imap.gmail.com:993"
#set spoolfile = "+INBOX"
set spoolfile = imaps://imap.gmail.com:993/INBOX
set ssl_starttls = yes
set ssl_force_tls = yes

# G to get mail
bind index G imap-fetch-mail
set editor = "vim"
set charset = "utf-8"
set record = "+[Gmail]/Sent Mail" # ''
set postponed="+[Gmail]/Drafts"
set header_cache="~/.mutt/cache/headers"
set message_cachedir="~/.mutt/cache/bodies"
set certificate_file=~/.mutt/certificates

Wichtig für die Mutt Konfiguration ist, dass

• set smtp_url = „smtp://…:587“
  Beim Einsatz von TLS würde es sonst zu einem TLS Fehler bei der Authentifizierung kommen.
• ssl_starttls & ssl_forcls sollten beide auf yes gesetzt sein.
• die Verzeichnisse, wie ~/.mutt/certificates, angelegt sind.
• bei Gmail ein Anwendungspasswort gesetzt wird.

Somit kann über die Konsole die Sicherung mit dem Programm Mutt und einem Google Konto versendet werden.

Automatisieren

Um regelmäßig ein BackUp zu erstellen und es dann auch noch via Mail zu versenden bediene ich mich eines Cron Jobs.

stefan@web:~ $ crontab -e

# m h  dom mon dow   command
0 4 * * * mysqldump -u root -pPASSWORT --all-databases --master-data | gzip > backup.sql.gz

Damit wird täglich um 4 Uhr ein Dump aller Datenbanken erstellt und dieses Abbild wird auch komprimiert. Der Eintrag funktioniert nur, wenn die entsprechenden Umgebungsvariablen bei der Ausführung gesetzt sind. Alternativ ist der komplette Pfad für die ausführbare Datei, hier mysqldump, anzugeben.

15 4 * * * /bin/tar -cpzf wpfiles001.tar.gz /var/www/html/

Fünfzehn Minuten später werden die WordPressdateien in ein komprimiertes Archiv kopiert.

30 4 * * *  echo "website backed up" | mutt -a backup.sql.gz -a wpfiles001.tar.gz -s "wordpress backed up" -- bakwp001@imatrix.at

Dreissig Minuten später werden alle Dateien des Backups an eine externe Mailadresse gesendet, die nur für diesen Zweck vorgesehen ist. Vor der Mailadresse des Empfängers muss man „–“ anführen, sonst wird der Empfänger nicht erkannt.

Natürlich gibt es noch andere Möglichkeiten, aber diese ist sehr übersichtlich. Es geht auch alles in einem Rutsch über einen Cron Job aufzurufen. Dazu werden die einzelne Befehle mit „&&“ verkettet.

0 4 * * * mysqldump -u root -pPASSWORD --all-databases --master-data | gzip > backup.sql.gz && tar -cpzf wpfiles001.tar.gz /var/www/html/ && echo "website backed up" | mutt -a backup.sql.gz -a wpfiles001.tar.gz -s "wordpress backed up" bakwp001@imatrix.at

Für meinen Geschmack nicht so übersichtlich. Sollte es komplexer werden, dann ist es ratsam das Ganze wahrscheinlich in eine „Batchdatei“ auszulagern und nur diese aufzurufen. Das kann zum Beispiel der Fall sein, wenn das Backup zu groß wird, um es als ein Anhang zu senden usw. Da könnte man dann mit dem Programm Split entsprechende Pakete erstellen.

Eine andere Alternative ist aber auch über WebDav und TLS die BackUps zum Beispiel auf einen Nextcloud Server zu verschieben.

Aufräumen ist nie schlecht, vor allem auch, um die Übersicht zu behalten. Dazu kann man auch wieder einen Cron Job anstossen.

45 4 * * * rm backup.sql.gz wpfiles001.tar.gz

Damit ist der Käse geschnitten und die WordPress Seite wird automatisch gesichert. Die Sicherung wird via Mail versendet und lokal bleibt nichts zurück.