Weblog Backup automatisieren

In ein Weblog wird häufig viel Zeit investiert. Umso ärgerlicher ist es, wenn Daten verloren gehen und dann kein Backup existiert. Viele denken, dass man ein Backup immer nur dann benötigt, wenn die Festplatte mal abraucht. Sicher wird der Webhoster regelmäßig Backups durchführen und wenn die Platte wirklich crashed, wird dieser schon dafür sorgen, dass alles wieder gut wird.

In der Praxis zeigt sich jedoch, dass in den seltensten Fällen aufgrund eines Hardware-Defekts ein Restore erforderlich wird. Am häufigsten sind Anwenderfehler der Grund, nicht selten werden Daten durch Malware zerstört und hin und wieder treibt auch schon mal ein Hacker sein Unwesen. In diesen Fällen werden einem die Backups des Providers wenig helfen.

Ein Weblog abzuschießen, ist eigentlich die einfachste Sache der Welt. Comment-Spammer machen vor, wie es geht. Statt 20 oder 30 Spams könnte man ein Weblog auch mit 20.000 Kommentaren bombardieren. Dann dürfte es etwas mühsam werden, die alle wieder zu entfernen. Wohl dem, der in so einem Fall über ein aktuelles Backup verfügt.

Voraussetzung für meinen Vorschlag ist, dass man über einen Shellzugang auf dem Server seines Providers verfügt, Cronjobs definieren kann und das Weblog die Daten in einer MySQL-Datenbank ablegt. Grundsätzlich funktioniert diese Lösung auch für andere Content-Management-Systeme, die MySQL als Datenbanksystem nutzen.

Wer sein Weblog bei einem Bloghoster hat, wird diese Lösung in aller Regel nicht nutzen können. Da bleibt einem oft nur die Export-Funktion der Weblog-Software. Berücksichtigen sollte man dabei aber, dass normalerweise weder Bilder noch die Einstellung im Weblog dabei gesichert werden. Evtl. angelegte Templates gehen ebenfalls verloren. Und sollte man tatsächlich jemals die Daten importieren müssen, kann es passieren, dass die Beiträge dann nicht mehr über dieselben Permalinks verfügen.

Schon deshalb würde ich mein Weblog nicht bei einem Bloghoster betreiben. Zumindest dann, wenn man einen halbwegs professionellen Anspruch hat, kommt man um eine automatisierte Backup-Lösung nicht umhin.

Christian Beier beschreibt in seinem Weblog eine Lösung, die im Wesentlichen wohl dem Serverbuch von Strato entnommen ist (via WebhostingBlog). Sie ist leider nur dann praktikabel, wenn man auf einem zweiten Server über Speicherplatz verfügt. Vermutlich leisten sich nur die wenigsten Blogger den Luxus, einen weiteren Webspace für das Backup anzumieten.

Ich persönlich fühle mich außerdem wohler, wenn sich immer eine aktuelle Kopie meiner Daten auf meinem heimischen PC befindet. Das könnte man natürlich immer Hand per erledigen. Die Erfahrung zeigt jedoch, dass man trotz guter Vorsätze nur hin und wieder eine Sicherung angelegt. Eine wirklich professionelle Backup-Lösung muss vollkommen automatisch ablaufen. Sonst hat man garantiert dann, wenn man es wirklich mal benötigt, keine aktuelle Sicherung.

Nun also zu meiner Lösung. Das Backup-Skript, das auf dem Server des Providers liegt, könnte etwa so aussehen:

#!/bin/bash
DATE=`date +"%Y%m%d"`
tar -c $HTML | gzip -c > backup/$DATE.tar.gz
mysqldump --add-drop-table -h localhost --user=$USER --password=$PW -B $DBNAME | gzip -c > backup/$DATE.sql.gz

Das Verzeichnis „backup“ ist vorher von Hand anzulegen. Die Variablen sind dabei durch die Daten der eigenen Installation zu ersetzen. $HTML steht für den Pfad, wo sich die Weblog-Installation befindet. Damit das Skript regelmäßig automatisch abläuft, richtet man einen Cronjob ein. Wer mit der Beschreibung hier nicht klarkommt, konsultiert am besten dazu die Anleitung seines Providers.

Das folgende Beispiel startet das Backup-Skript immer um 7 Uhr morgens. Wer weiß, wie man mit dem Editor vi umgeht, ruft crontab –e auf und fügt die folgende Zeile hinzu:

* 7 * * * HOME/backup.sh

HOME ist dabei durch das Verzeichnis zu ersetzen, wo sich das Backup-Skript befindet. Wer als root auf einem dezidierten Server arbeitet, kann alternativ die Datei /etc/crontab editieren und diese Zeile hinzufügen:

* 7 * * * root HOME/backup.sh

Der Knackpunkt ist natürlich, wie man die Backup-Daten automatisiert auf den Rechner zu Hause bekommt. Dafür dient die folgende Batch-Datei für den Windows-PC daheim:

pscp -pw KENNWORT USER_NAME@MEINE_DOMAIN.de:/backup/* c:\backup
plink MEINE_DOMAIN.de -l USER_NAME -pw KENNWORT rm backup/*

Die Programme „pscp“ und „plink“ sind Freeware. Man kann sie sich z.B. hier herunterladen. Mit pscp werden zunächst alle Daten aus dem Backup-Verzeichnis auf dem Server lokal abgespeichert und mit Hilfe von plink wird das Unix-Kommando rm aufgerufen, das das Backup-Verzeichnis auf dem Server leert.

Beim ersten Aufruf wird man aufgefordert, die Signatur des Servers zu akzeptieren. Diese Aufforderung kommt später nicht mehr. Unschön ist dabei vielleicht, dass man die Kennwörter im Klartext auf der Festeplatte ablegen muss. Diese Anleitung verrät, wie es auch ohne geht. Man muss dafür aber erst ein paar Vorarbeiten leisten.

Nun sollte man noch dafür sorgen, dass auch die Batch-Datei regelmäßig aufgerufen wird. Eine Möglichkeit ist, eine Verknüpfung der Datei in den Autostart-Ordner zu legen. Dazu zieht man mit der rechten Maustaste die Batch-Datei nach C:\Dokumente und Einstellungen\DEIN_USERNAME \Startmenü\Programme\Autostart. Jedes Mal, wenn man sich auf seinem Rechner einloggt, werden dann die neuesten Sicherungen heruntergeladen.

Wenn der PC immer zur selben Zeit an ist, kann man auch unter Windows einen Cronjob laufen lassen, der die Batch-Datei aufruft. Dazu klickt man in der in der Systemsteuerung auf „Geplante Tasks“. Ein Assistent hilft einem dann bei der Konfiguration. Es macht gar nichts, wenn der Rechner mal nicht zu dieser Zeit läuft. Die Backups bleiben solange auf dem Server, bis sie heruntergeladen werden.

Man sollte dann unbedingt mal einen Blick in die gesicherten Daten werfen. Mit Winzip kann man zum Beispiel unter Windows gz-Dateien entpacken. Wichtig wäre eigentlich auch, mal den Ernstfall zu erproben und ein Restore durchzuführen. Das macht man vielleicht nicht unbedingt bei einem im Einsatz befindlichen System.

Erwähnen sollte ich noch, dass ich keine Garantie für die Beschreibung hier übernehme.

Comments are closed.