WordPress-Backup: BackWPup & Amazon AWS S3

Backup

Zum Backuppen einer WordPress-Instanz empfehle ich aus eigener langjähriger und leidvoller Erfahrung BackWPup.

Vermutlich läuft dieses nicht richtig (WordPress Cron), wenn WordPress auf einer Windows-Maschine gehostet wird (aber dies widerspricht ohnehin der offiziellen WordPress-Empfehlung).

Standardmäßig werden auch sämtliche Plugins komplett gebackupped (bis auf das BackWPup-Plugin selbst) – was v.a. nützlich ist, wenn man auf seiner Instanz selbstgeschriebene Plugins verwendet.

In der BackWPup Version 3.5.1 gab es das Problem, dass der Windows zipper den . Ordner weder angezeigt und noch entzippt hat. In diesem Ordner wurden jedoch u.a. das Datenbank-File gespeichert.

Datensicherung im Verzeichnis auf WP-Instanz

Das einfachste Speicherziel ist Ziel:Verzeichnis, da man das sofort und ohne weitere Anmeldung bei externen Hostern umsetzen kann. Diese nutzen natürlich nur, wenn Du beispielsweise durch ein Update die WordPress-Instanz zerschossen hast. Geht jedoch gleich Deine Festplatte über die Wupper, verlierst Du Deine Backups logischerweise auch.

Die Backup-Dateien liegen anschließend unter wp-content\uploads. Diese kann man dann entzippen und grob auf Vollständigkeit überprüfen (v.a. Bilder und Datenbank-Backup sind wichtig). Habe es gerade überprüft: die geschedulten Backups haben 100% funktioniert.

Sinnvollerweise backupped BackWPup die gebackuppten Dateien selbst nicht wieder, was ja unnötig wäre und zu exponentiellem Platzverbrauch führen würde.

Datensicherung via AWS S3-Service

Eine vernünftige Backup-Strategie legt die Backups natürlich auf mehreren anderen, weit entfernten Computer ab, damit bei einem Totalausfall des Computers der WP-Instanz die Backups nicht mitverloren gehen. Hier bietet sich mit dem AWS S3-Service die Cloud an. Natürlich werden dann die Daten bei einem US-Fremdanbieter gespeichert und man muss selbst entscheiden, ob die Daten dafür zu sensibel sind und ob man das dann wirklich will.

Folgendes Backupkonzept bietet sich m.E. an, da je älter die Backups sind, desto weniger „dicht“ müssen sie aufbewahrt werden. Ich richte also 5 Aufträge ein: 24 stündliche, 7 tägliche, 4 wöchentliche, 12 monatliche und 10 jährliche Backups. Beziehungsweise konkreter ausgedrückt, einen Auftrag bei dem stündlich ein Backup erfolgt und bei dem 24 Dateien im Ordner behalten werden, wie es im Tab Ziel: XY heißt. Dies ist für mich ein guter Kompromiss aus Abdeckung aller möglichen Restore-Bedürfnisse im Notfall und Kostenersparniss, denn Backups kosten Geld für deren Speicherung.

Die Storage Class Standard-IA ist deutlich günstiger als Standard, rechnet jedoch mindestens 30 Tage Speicherung ab – selbst wenn die Datei nach einem Tag wieder gelöscht wird (Details). Daher verwende ich für die monatlichen und jährlichen Backups Standard-IA und für den Rest Standard. Zu S3 gesendete Dateien und Datei-Löschungen sind kostenfrei – nur Datenabholungen von S3 sind zusätzlich zur eigentlichen Speicherung kostenpflichtig – da Restores selten und die Abholung zudem noch extrem günstig ist, ist dieser Fall vernachlässigbar (Preise).

Irland ist mit die günstigste Region weltweit für die Speicherung in S3 und unterliegt dem EU-Datenschutz, daher richte ich mir dort ein Bucket für alle meine Backups ein. Dann richte ich mir für jede WordPress-Instanz noch einen Ordner ein und je einen Subordner für die stündlichen, täglichen, … Backups:

Ein Backup meiner WordPress-Instanz wiegt aktuell 500 MB. Es ergeben sich also mit 35 Backups (insg. 17,5 GB) in Standard Storage Class (17,5 GB * 2c) monatliche Kosten von 34 cent. In der Standard-IA Storage Class benötige ich 22 Backups (insg. 11 GB), was 11 GB * 1 cent = 11 cent bedeutet. Mein Rundumsorglos Backupstrategie kostet mich bei Amazon AWS also nur 45 cent/Monat. Durch die Verwendung des Glacier-Service ließen sich die Kosten sicherlich noch weiter drücken – aber bei den Beträgen ist das natürlich witzlos.

So sieht die Konfiguration für S3 bei BackWPup am Beispiel des Auftrags Stündliches Backup aus:

Troubleshooting

Konkrete Probleme bei der Verwendung von BackWPup und AWS S3 traten auf, da mein IAM-User noch keine S3-Zugriffsrechte hatte.

Des Weiteren hatte ich den falschen S3-Server (bzgl. Region) angegeben: der muss bei WP-Backup dem entsprechen, was beim Bucket angelegt wurde.

Auch musste ich wegen eines Issues in BackWPup sicherstellen, dass keiner der Aufträge zur gleichen Minute startete – es können aktuell nicht mehrere Backups gleichzeitig laufen.

Restore

Beim Upgrade von WordPress hat’s mir tatsächlich meinen Admin-Bereich zerschossen, weshalb ich restoren musste.

Die Dateien aus dem gezippte Backup-Archiv extrahieren. Als Sicherheitsfanatiker kopiere ich die aktuellen Dateien aus meiner WP-Instanz trotzdem nochmal irgendwohin. Dann lösche ich die Dateien in der WP-Instanz vollständig. Dann kopiere ich die extrahierten Dateien in den root-Ordner der WP-Instanz. Und tatsächlich hat es funktioniert – ich habe den gleichen Stand, wie vor meinem verunglückten Updateversuch. Für diesen Fall sogar ohne auch nur eine Operation an der Datenbank durchführen zu müssen.

Ein Gedanke zu „WordPress-Backup: BackWPup & Amazon AWS S3“

Kommentare sind geschlossen.