WordPress-Backups mit BackWPup auf Backblaze B2 (ergo S3-Speicher)

Manchmal sind es diese Zufallsfunde, die einem das Leben erleichtern – oder wie in diesem Fall auch mal eben eine kleine Inspiration für einen neuen Blog-Beitrag bieten. In meinem Fall habe ich vor kurzem wieder einmal eine neue WordPress-Installation aufgesetzt und auf der Plugin-Installations-Seite nach meinem bevorzugten Backup-Plugin gesucht: BackWPup. Dieses Plugin erfüllt nicht nur seinen Zweck in vorbildlicher Art und Weise, es ist auch bzgl. der ebenfalls angebotenen „Pro“-Version kein bisschen aufdringlich, sondern weist nur dezent auf seiner Informationsseite darauf hin, dass eine erweiterte Fassung gegen Entgelt erworben werden kann.

Doch auch in der „Free“-Variante bietet BackWPup für meine Zwecke alles, was man für das Backup eines WordPress-Blog braucht. So lassen sich etwa Backups in einem Verzeichnis speichern, als Mail versenden, bei Microsoft Azure, Dropbox oder weiteren Diensten speichern, oder auch ganz einfach mittels des guten, alten FTP (File Transfer Protocol) auf einen entsprechenden Server packen. Ebenfalls werden unterschiedliche S3-Provider (Simple Storage Service), darunter Amazon AWS S3, Google Cloud Storage und DigitalOcean angeboten. Nur Backblaze, mein bevorzugter Cloud-Storage-Provider für die Speicherung von Backups, fehlte bislang bzw. gab es keine Möglichkeit, weitere S3-Ziele hinzuzufügen.

Zufallsfund und tolles Plugin: Advanced S3 Destinations for BackWPup

Bei der Suche im Plugin-Verzeichnis fiel mir jedoch ein Plugin namens „Advanced S3 Destinations for BackWPup“ auf, das versprach, genau diese vermisste Funktionalität hinzuzufügen. Somit sollte sich jedes beliebige S3-Ziel verwenden lassen, sofern der Dienst kompatibel zum von Amazon AWS (Amazon Web Services) definierten S3-Standard ist. Backblaze beschreibt die Kompatibilität des bei ihnen „Backblaze B2“ genannten S3-Speichers in einem eigenen Beitrag und gibt ebenfalls Hinweise, wie die jeweiligen Anwendungen konfiguriert werden müssen. Laut dieses Beitrags gilt die Kompatibilität auch erst für Buckets, die nach dem 04.05.2020 erstellt worden sind, ggf. wären somit neue Buckets zu erstellen.

Backblaze-Buckets und -Preise

Ein Bucket ist eine logische Speichereinheit innerhalb des S3-Speichers, viel weiter möchte ich auf die Grundlagen von S3 gar nicht eingehen. Buckets bieten somit die Möglichkeit, den potenziell unendlich großen zur Verfügung stehenden Cloud-Speicher zu strukturieren und insbesondere dessen Zugriffsrechte zu verwalten. Die Nomenklatur stammt von AWS, sicherlich hätte man auch einfach „Verzeichnis in erster Ebene“ dazu sagen können, aber auch das hätte wieder zu anderen Fragen geführt, beispielsweise wieso sich Verzeichnisse der ersten Ebene von weiteren Verzeichnissen darin unterscheiden usw.. Auf weitere Erläuterungen, etwa zur Anmeldung bei Backblaze möchte ich an dieser Stelle gar nicht weiter eingehen, vielleicht sind noch die Preise erwähnenswert, die sich nach der Nutzung bzw. des benötigten Speicherplatzes richten.

Die ersten 10 GB sind tatsächlich kostenlos, zusätzlich werden Transaktionen wie Up- oder Downloads berechnet, wobei Backblaze in jedem Fall zu den günstigeren Anbietern gehört. Dabei ist zu beachten, dass zwar beispielsweise ein initiales und somit vollständiges Backup beim Upload zu Buche schlägt, das tägliche bzw. inkrementelle Backup jedoch weit weniger Daten überträgt, sondern nur noch Änderungen hinzufügt. Da sich sowohl Obergrenzen als auch Warnungen bei Überschreitung von Limits setzen lassen sollte man vor teuren Überraschungen geschützt sein.

Bei Backblaze gibt es einen Menüpunkt „Berichte„, darin werden Speicher-Nutzungsdaten wie „durchschnittlich gespeicherte GB„, „Heruntergeladene GB„, Transaktionen aufgeteilt in Transaktions-Klassen A, B und C usw. angegeben. Dabei spielt die Anzahl der Transaktionen für die Abrechnung in meinem Nutzungsszenario eine eher untergeordnete Rolle, wesentlich relevanter für die Abrechnung ist der tatsächlich genutzte Speicherplatz. Nur um einen groben Anhaltspunkt zu liefern – während der letzten Monate waren durchschnittlich 430 GB Backup-Daten gespeichert, die mich inklusive Umsatzsteuer weniger als drei Dollar pro Monat gekostet haben (genauer: zwischen $2,24 und $2,69). Würde ich ausschließlich die Backup-Daten dieses Blogs speichern, wären es – wenn überhaupt – nur ein paar Cent. Ein meines Erachtens vernachlässigbar geringer Betrag für einen sehr sinnvollen Zweck.

Backup-Strategie

In meinem Fall nutze ich Backblaze B2 für nahezu jedes Backup, wobei die Einteilung pro Server oder auch Service erfolgt. Beispielsweise sichere ich einen Server namens „stralsund“ in einem Bucket „bak-stralsund“. Dafür sind wiederum Zugriffsdaten generiert, die ausschließlich den Zugriff auf dieses Bucket erlauben, nicht jedoch auf ein anderes, in dem etwa Daten eines anderen Servers gesichert werden. Nebenbei erwähnt verschlüsselt das ansonsten verwendete Backup-Programm Restic die Daten, bevor sie in die Cloud geschickt werden.

Dabei ist Backblaze jedoch nicht das einzige Backup-Ziel, denn um auf Nummer sicher zu gehen, wird ein weiteres Backup in eine Hetzner Storage Box geschrieben, und/oder je nach Anforderung auch noch intern auf einem NAS oder einer externen Festplatte gesichert, was der 3-2-1-Regel zumindest nahekommt.

Auf zum Backup mit BackWPup!

Für dieses sowie das zweite Blog habe ich somit zunächst pro Blog je ein Bucket bei Backblaze B2 angelegt.

Nach dem Anlegen des Buckets ist dieses erst einmal nur da – und könnte mittels Master-Anwendungsschlüssel, d.h. dem Generalschlüssel, der für alle Buckets gültig ist und einmalig bei der Anmeldung zum Backblaze-S3-Dienst angelegt wird, verwendet werden. Dass dies kaum sinnvoll ist, erschließt sich von selbst, schließlich sollen die einschlägig bekannten männlichen Menschen mit Kapuzenpullover und grünen Buchstaben auf dem Bildschirm nicht auch noch den Zugriff auf alle gespeicherten Backups erhalten, falls ihnen es denn gelingen sollte, das WordPress-Blog zu penetrieren.

Schlüsselerlebnis

Daher sollte ein Anwendungsschlüssel (Application Key) generiert werden, der dahingehend konfiguriert wird, dass damit ausschließlich Zugriffe auf das jeweilige Bucket erlaubt sind:

Die Einstellung „Auflistung aller Bucket-Namen gestatten“ wird als notwendig für die S3-kompatible API angegeben, also erlaube ich dies einfach mal. Mit „Create New Key“ wird der Anwendungsschlüssel generiert, bestehend aus keyID und applicationKey. Der Hinweis, dass diese Angaben nur einmal angezeigt werden, ist übrigens ernst zu nehmen!

Der selbst gewählte und in meinem Fall einem Schema folgende Name des Keys (keyName) ist hingegen weniger ein Geheimnis und ist auch in der Liste der Anwendungsschlüssel zu sehen.

Somit besteht der nächste Schritt aus dem Notieren beider Teile des Application-Keys, im besten Fall wird dieser im hoffentlich bereits vorhandenen Passwort-Manager-Tool sicher abgespeichert.

Einrichtung eines S3-Ziels bei BackWPup

Mit diesen Angaben kann die Konfiguration von BackWPup stattfinden. Das „Advanced S3 Destinations for BackWPup„-Plugin fügt BackWPup in den Einstellungen einen Reiter „S3 Destinations“ hinzu. Darin werden zunächst nur neue S3-Ziele definiert, die der Liste der bei BackWPup standardmäßig vorhandenen Liste der S3-Ziele hinzugefügt werden können.

Sowohl Unique ID als auch Label sind frei wählbar, als Endpoint (-URL) ist der Endpoint von Backblaze einzutragen, der einem zugeordnet wurde. Dieser ist in den Angaben zum jeweiligen Bucket in der Backblaze-UI sichtbar.

Im Unterschied zu Amazons S3 Service wird die Region nicht explizit gewählt, sie versteckt sich vielmehr in der Endpoint-URL. Diese Angabe ist jedoch zwingend notwendig, da ansonsten Backblaze als S3-Ziel über die von BackWPup verwendeten API-Funktionen nicht angesprochen werden kann. Die Region ist dabei der zweite Abschnitt der Endpoint-Angabe, wie sie von Backblaze genannt wird, im Beispiel hier „us-west-002„. Ferner müssen für die S3-Kompatibilität „v4“ Signatures genutzt werden, was jedoch bereits die Vorgabe darstellt.

Backup-Aufträge in BackWPup

Der letzte Schritt der Konfiguration besteht aus dem Anlegen des eigentlich Backup-Auftrags. BackWPup unterstützt mehrere Backups, die sich im Detail unterscheiden können. So können die zu sichernden Objekte wie Dateien, Plugins, Datenbank etc. gewählt werden, ebenso wie unterschiedliche Ziele, wobei auch mehrere Ziele pro Auftrag möglich sind. Je nach Blog-Größe können vollständige Backups, etwa bei der Verwendung vieler Bilder durchaus umfangreich werden. Das Hochladen derselben Backup-Datei zu unterschiedlichen Zielen, etwa in ein FTP-Verzeichnis sowie einen S3-Objektspeicher, spart somit Zeit. Die Sicherung  ausschließlich geänderter Verzeichnisse zu S3, Dropbox, Rackspace Cloud Files oder Microsoft Azure bietet übrigens die Pro-Version von BackWPup an.

In meinem Fall verzichte ich darauf und lege vielmehr einen Backup-Auftrag pro Ziel an. Beim Anlegen oder auch Ändern eines Auftrags wird das Ziel im Reiter „Allgemein“ im Bereich „Zielverzeichnis des Auftrags“ spezifiziert. Die Anwahl von „Backup zu einem S3 Service“ blendet dann rechts oben einen weiteren Reiter „Ziel: S3 Service“ ein. Der Wechsel der Reiter bzw. Tabs kann beliebig erfolgen, letztlich sind alle Einstellungen leicht verständlich und selbsterklärend, weshalb ich auch nicht näher auf alle Funktionen von BackWPup eingehen möchte.

Backups zu Backblaze B2 (ergo S3 Speicher)

Das zuvor definierte S3-Ziel „Backblaze S3“ findet sich in den Einstellungen des S3-Service-Tabs in der Liste zur Wahl des S3 Service.

Nachdem „Backblaze S3“ ausgewählt ist, müssen die Zugangsdaten eingetragen werden. Hierbei ist zu beachten, dass sich die Benennung der einzelnen Parameter des Anwendungsschlüssels ein wenig von der Amazon AWS S3 Nomenklatur unterscheidet.

Der bei Amazon „Access Key“ (auch Access Key ID) genannte Teil des Application Keys ist bei Backblaze die „keyID„,  während der „Secret Key“ (auch Secret Access Key) von AWS bei Backblaze S3 den „applicationKey“ darstellt. Sobald beide Parameter eingetragen werden, prüft BackWPup im Hintergrund den Zugang und fragt bereits die Liste der zur Verfügung stehenden Buckets ab.

Sollte nach der Eingabe von „Access Key„, d.h. KeyID und „Secret Key“ (applicationKey) keine Liste unter „Bucket-Auswahl“ erscheinen, oder der Versuch gar durch eine Fehlermeldung gekrönt werden, ist das ein sicheres Zeichen, dass etwas nicht stimmt und überprüft werden muss. Ansonsten kann das zuvor angelegte Bucket einfach aus der Liste ausgewählt werden.

Die restlichen Einstellungen sind ebenso selbsterklärend und bleiben zunächst bei der Voreinstellung – mit einer Ausnahme, der „Server side encryption„.

Backblaze B2 bietet, genau wie Amazon AWS S3, eine serverseitige Verschlüsselung an. Dabei werden die Schlüssel jedoch vom Provider, also Backblaze bzw. Amazon verwaltet. Hier kann sich durchaus eine gewisse Sinnfrage stellen. Denn wenn die oben angedeuteten bösen Buben den Provider vollständig „hacken“ sollten, bestünde zumindest die Möglichkeit, an die Schlüssel zu gelangen, und somit ebenso an alle Daten der dort gelagerten Backups. Immerhin schützt die Verschlüsselung jedoch vor Gelegenheits-Dieben, oder auch falscher Konfiguration (z.B. öffentlichen statt privaten Zugriffs) in den Bucket-Einstellungen. Ebenfalls ist es in der Backblaze-UI, über die ein Dateimanager-artiger Zugriff auf die gespeicherten Dateien erfolgen kann, nicht möglich, verschlüsselte Dateien herunterzuladen.

Da die Option der client-seitigen Verschlüsselung ausschließlich in der Pro-Verson von BackWPup angeboten wird, ist diese serverseitige Verschlüsselung zumindest besser als gar keine. Über rechtliche Auswirkungen der Speicherung in den USA bzgl. DSGVO möchte ich hier lieber nicht spekulieren, wobei Backblaze auch die Möglichkeit der Speicherung in Rechenzentren innerhalb Europas anbietet. Leider ist dies nur einmalig beim Anlegen eines Accounts wählbar, anschließend ist man darauf festgelegt und kann nicht wie bei anderen Cloud-Diensten beliebig zwischen unterschiedlichen Ländern oder Kontinenten wechseln.

Erster Backup-Lauf

Ist der Backup-Auftrag fertig konfiguriert, kann er in BackWPup direkt ausgeführt werden:

Der Warn-Hinweis hängt in dem Fall nicht direkt mit BackWPup zusammen, die Datenbank funktioniert, wird auch trotzdem gesichert, vielmehr handelt es sich um ein Problem, was durch ein Update der Datenbank-Version entstanden ist.

Nach Beendigung des Backup-Prozesses wird der Erfolg entsprechend angezeigt:

Der Auftrag wurde ausgeführt, ferner kann ein ausführliches Logfile angezeigt werden.

Gut geplant ist halb ge-back-upt

Natürlich möchte man Backups nicht manuell starten, sondern automatisch etwa einmal täglich ausführen lassen, mehr dazu im Reiner „Planen“ eines Auftrags. Bekannte web-basierte Tools zur Server-Konfiguration wie Plesk oder ISPconfig bieten einen bequemen Weg zur Einrichtung von regelmäßig auszuführenden Aufgaben (sog. Cron-Jobs). Darin kann einfach eine beliebige URL angegeben werden. Beim Aufruf dieser URL, die in einem BackWPup-Auftrag unter „Planen“ -> „Auftragsplanung“ -> „Auftrag starten“ – „mit einem Link“ sichtbar ist, wird der Backup-Prozess angestoßen und ausgeführt. Falls die BackWPup-Option „Benachrichtigung bei Fehlern“ aktiviert wurde, erhält man ausschließlich dann eine Mail, wenn es während der Ausführung eines Backup-Laufs zu Fehlern gekommen ist, ansonsten verhält sich BackWPup dankenswerterweise ruhig und geht einfach ohne Aufsehen seiner Arbeit nach. Natürlich können Cronjobs ebenso auf System-Ebene definiert werden, in dem Fall wäre die Nutzung der WordPress-CLI eine sinnvolle Option.

Alle Backups sind direkt unter dem Menüpunkt „Backups“ verwaltbar, so findet sich dort eine Liste der zur Verfügung stehenden Backups, gegliedert nach Backup-Zielen. Die Backup-Dateien können gelöscht oder heruntergeladen werden, das automatische Wiederherstellen bietet hingegen nur die Pro-Version von BackWPup. Dies klingt nach einem größeren Manko als es ist, denn im Falle eines Falles würde ich sowieso die jeweilige Site aus einer „sauberen“ Installation erzeugen, insbesondere wenn die Wiederherstellung aufgrund des Eindringens eines der bereits genannten Hacker-Stereotypen notwendig geworden wäre.

Ebenso sind die von BackWPup bzw. dank der Hilfe des Advanced S3 Destinations for BackWPup Plugins zu Backblaze hochgeladenen Backups auch in der Web-UI sichtbar  (hier im Beispiel noch in einer unverschlüsselten Form; ansonsten wird vor dem Dateinamen ein Schlüssel-Symbol angezeigt):

Backup für alle

Das bereits sehr gute Plugin BackWPup wird durch das Plugin-Plugin (diese Wortschöpfung erlaube ich mir an dieser Stelle) „Advanced S3 Destinations for BackWPup“ noch besser. In meinem Fall kann ich so direkt von BackWPup zwei unterschiedliche Ziele bedienen, ohne auf die bei BackWPup vorkonfigurierten S3-Objektspeicher-Dienste angewiesen zu sein. Auch die Open-Source-S3-Speicher müssten somit bei S3-kompatibler API ansprechbar sein, und könnten eine Alternative zu den bekannten Anbietern darstellen. Zumindest sofern die Möglichkeit besteht, diese in einem örtlich entfernten Rechenzentrum zu betreiben, schließlich soll das Backup gerade vor lokalen Katastrophen bewahren.

Der Rant am Rand

Einen kleinen Hinweis muss ich noch los werden – nein, die genannten Plugins sind super, sowohl BackWPup als auch das Advanced S3 Destinations for BackWPup Plugin haben mich restlos überzeugt. Nur manchmal empfinde ich ein gewisses Verhalten in der Community seltsam bis fragwürdig.

Auf der WordPress-Plugin-Seite von „Advanced S3 Destinations for BackWPup“ werden neben der Beschreibung auch ein paar Daten zum Plugin angegeben, beispielsweise die Anzahl der aktiven Installationen. Natürlich ist diese Angabe nur geschätzt, und dass das Plugin in wesentlich geringerem Maße als BackWPup selbst genutzt wird, ist ebenso logisch, allein wenn man die Historie betrachtet, so ist BackWPup wesentlich älter und hat eine wesentlich größere Verbreitung.

Da das „Advanced S3 Destinations for BackWPup“-Plugin zum Zeitpunkt meiner ersten Tests weder eine Bewertung, noch ein Review erhalten hatte, wollte ich meine Begeisterung im WordPress Plugin-Directory kurz mitteilen, vielleicht würde sich der Autor ja über eine Fünf-Sterne-Bewertung freuen. Verbunden mit dem Hinweis der Nutzung von Backblaze habe ich also kurzerhand drei Sätze als Review verfasst und das Plugin mit der bestmöglichen Anzahl von Punkten bewertet.

So weit, so gut? Nicht ganz. Eine Dreiviertelstunde später schrieb mir ein Moderator, dass er mein Review gelöscht hätte, weil ich dort eine URL eingesetzt hatte. Hmm…

Ok, das Setzen von URLs verstößt gegen die Community-Richtlinien. Gut, wir sind im WWW, da sind Links natürlich nicht erwünscht, klingt sehr logisch. Nein, was ich damit sagen will – ich akzeptiere derartige Richtlinien selbstverständlich, auch wenn ich sie in diesem Fall für nicht sinnvoll halte. Und sicherlich gab es auch einen Hinweis in kleiner Schrift, was erlaubt sei und was nicht, den ich in meinem Eifer und der Begeisterung glatt überlesen hatte.

Aber warum wird das dem Review-Autoren nicht direkt während bzw. nach der Eingabe beim Abschicken des Reviews mitgeteilt? Jede drittklassige Forum-Software kann per Regexp zumindest in den meisten Fällen URLs erkennen, Inhalte auf erlaubte Zeichen prüfen oder ähnliches. Dieses direkte Feedback hätte es mir gestattet, die drei Review-Zeilen kurz zu überarbeiten und dann erst das fertige Review abzuschicken. Warum muss sich hier erst ein Moderator einschalten? Warum wurde mein Beitrag erst akzeptiert, ich meine sogar, mich zu erinnern, dass auf der Plugin-Seite die Sterne-Bewertung inklusive Kommentar angezeigt wurde, dann aber im Nachhinein abgelehnt? Und wenn sich die WordPress-Community schon den Luxus von menschlichen Review-Kommentatoren leistet, warum werden URLs dann nicht daraufhin geprüft, ob sie – wie in meinem Fall – Hinweise auf die Hilfe-Seiten eines S3-Dienstleisters bieten, so dass die nicht-deutschsprachigen Leser, die sich diesen langen Artikel wohl kaum zu Gemüte führen werden, einen kleinen Tipp zur Nutzung des Plugins erhalten hätten, oder aber den verständlicherweise unerwünschten Spam beinhalten? (Für WordPress gibt es doch mehrere Plugins, die die automatische Prüfung wunderbar erledigen, ich nutze z.B. Antispam Bee, das sehr zuverlässig Spam und ähnliches erkennt.) Warum erhielt ich einen Link zum (gelöschten? als „gelöscht“ markierten?) Beitrag, und als ich diesem gefolgt bin, wurde dieser zwar noch angezeigt, es war aber nicht möglich, ihn direkt zu editieren, um die URL zu entfernen. Warum befinden sich Reviews in einem „Support-Forum“? Rein thematisch sind Reviews doch etwas anderes als Support. Warum befindet sich oberhalb des Eingabefeldes überhaupt ein Menüpunkt zur Link-Eingabe mitsamt Dialogfenster zur Link-Erstellung, wenn Links nicht erlaubt sind?

Daraufhin habe ich versucht, eine neue Review zu erstellen, natürlich ohne Angabe von URLs. Diese war merkwürdigerweise nicht direkt auf der Plugin-Seite sichtbar. Auch heute, mehr als 24h später, ist das Plugin noch immer nicht bewertet und hat keine Review erhalten – obwohl sich mein Beitrag dazu irgendwo auf den WordPress-Seiten befindet. In welchem Zustand dieser aktuell sein mag, kann ich jedoch nicht ergründen. Herzliche Grüße an Herrn Schrödinger und sein Tierchen. Gehe ich auf der Plugin-Seite auf „Reviews“, ist nichts zu sehen, auch wenn ich bei WordPress.org eingeloggt bin. Klickt ich auf „Add my review“, wird als Anzahl „0 reviews“ angegeben, darunter aber der Beitrag angezeigt, also scheint er doch irgendwie noch vorhanden zu sein?

Insgesamt war diese erste Erfahrung mit WordPress Plugin-Reviews für meine Motivation, weitere Reviews zu verfassen, nicht gerade förderlich. Und das ist auch das Bedauerliche dabei, denn wie des Öfteren erwähnt nutze ich WordPress gerne, und schätze dabei sehr die Arbeit aller Beteiligten, ob Core-Entwickler, Plugin-Autoren, Theme-Designer, Übersetzer, Code-Reviewer usw..