Webserver-Backup für Dummies 2: Backup in der Cloud

Nachdem ich im ersten Teil beschrieben habe, wie ich automatisch lokale (d.h. auf  dem Server selbst liegende) Sicherungen wichtiger Dateien und der Datenbanken erzeuge, wird es nun Zeit, das Ganze zu einem “echten” Backup auszubauen.

Natürlich empfiehlt es sich, die Sicherungen herunterzuladen und auf dem heimischen PC nochmals abzulegen. Aber wie es der Zufall will, kann es passieren, dass man einmal etwas wiederherstellen muss, wenn man gerade unterwegs ist und nur ein Notebook mit UMTS – oder noch schlimmer, nur ein Internet-Cafe – zur Verfügung steht. Mit diesen Mitteln kommt man vielleicht per Putty auf den Server, aber nicht an die Backups, die jetzt so dringend nötig wären.

Die hier vorgestellte Lösung kommt, wenn sie fertig eingerichtet ist, mit einem Shell-Zugang auf den Server aus, um jede beliebige Datei, Datenbank oder auch ganze Verzeichnisse wiederherstellen zu können. Um sie nutzen zu können, ist ein Root-Zugang auf dem Server oder VPS erforderlich. Und wieder gelten alle hier gemachten Angaben für Debian.

Die Sicherungen selbst werden wir bei Amazon S3 lagern, in der Cloud also. Damit keine unbefugten Augen unsere Daten ausspähen, werden wir alles verschlüsseln. Amazon garantiert eine Verfügbarkeit von 99,99% (das ist deutlich besser als bei den meisten Webhosting-Providern), und auch wenn es sich hierbei um einen bezahlten Service handelt, liegen die monatlichen Kosten tatsächlich nur im Pfennigbereich. (Eine Preisübersicht findet sich hier.)

Abgeschaut habe ich mir die Vorgehensweise in einem Posting von Michael Martin (ProBlogDesign) und gebe die nötigen Schritte hier mit Michaels freundlicher Genehmigung übersetzt und etwas erweitert wider.

Überblick über die Vorgehensweise

Wir beginnen mit den Zielen für unseren Backup-Mechanismus.

• Jeden Tag zu einer bestimmten Zeit, die wir definieren, startet der Backup-Prozess.
• Eine Sicherung der Datenbank wird erzeugt und auf unserem Webserver abgelegt.
• Anschließend nimmt die Backup-Routine Kontakt zu den Amazon-S3-Servern auf und legt dort eine Sicherung aller Dateien an, die wir definieren.
• Alternativ kann auch eine inkrementelle Sicherung durchgeführt werden. Dabei wird lediglich das Delta zur vorangegangenen Sicherung übertragen.
• Vor dem Ablegen der Sicherungen bei Amazon werden diese verschlüsselt, so dass niemand außer uns in der Lage ist, sie einzusehen.

Schritt 1: Verschlüsselung einrichten

Die Verschlüsselung ist ein äußerst wichtiger Punkt für ein Backup, das in fremde Hände gelegt wird. Diesen Schritt solltet Ihr also keinesfalls überspringen.

Hierfür werden wir das bekannte GnuPG (GNU Privacy Guard) einsetzen. Es arbeitet mit zwei Schlüsseln:

• einem öffentlichen Schlüssel: Dieser wird zum Verschlüsseln der Daten benutzt. Er kann von jedermann eingesehen werden.
• einem privaten Schlüssel: Dieser wird zum Entschlüsseln der Daten benutzt. Er muss sicher aufbewahrt werden und darf an niemanden weitergegeben werden.

Die zwei Schlüsseldateien, die GPG erzeugt, bilden ein Schlüsselpaar. Dateien, die mit dem öffentlichen Schlüssel verschlüsselt wurden, können nur mit dem privaten Schlüssel wiederhergestellt werden. Wenn man seinen privaten Schlüssel verliert, hat man keine Chance mehr, an seine Daten zu kommen.

Zum Erzeugen der Schlüssel begeben wir uns nun auf die Kommandozeile des Servers:

gpg --gen-key

Das Programm fragt nun einige Angaben ab:

• Key type – DSA and Elgamal (Default wählen)
• Key size – 2048 bits (Wieder Default wählen)
• Expiration – Do not expire (der Schlüssel muss für unsere Belange nie ablaufen)
• Name, Kommentar und E-Mail-Adresse – im Grunde ist es egal, was man hier angibt. Es ist aber sinnvoll, die Angaben zu notieren. Für den Fall, dass man später noch weitere Schlüssel erzeugt, ist es gut, mit Hilfe dieser Angaben die Übersicht zu behalten.
• Passphrase - Hier ein beliebiges Wort oder einen beliebigen Satz eintippen (und unbedingt in genau der richtigen Schreibweise notieren!)
• Anschließend ist von “Entropie” die Rede. Der Server benötigt jetzt ein wenig Aktivität, um Zufallszahlen erzeugen zu können. Dafür kann man einfach ein paar Webseiten auf dem Server im Browser aufrufen oder ein paar Kommandos in einem anderen Terminalfenster ausführen.

Kurz darauf ist der Schlüssel fertiggestellt, und es werden einige Zeilen ausgegeben, unter anderem etwa so etwas:

pub   1024D/19A5D849 2010-08-28

Der Teil, der hier 19A5D849 lautet, ist die ID des Schlüssels, und die werden wir später benötigen.

Wenn man seine Schlüssel-ID einmal vergisst, kann man sie mit dem Befehl

gpg --list-keys

später jederzeit noch einmal anzeigen lassen.

Noch ein wichtiger Hinweis: Sollten die Schlüssel jemals verloren gehen (z.B. durch einen Servercrash), ist es sinnvoll, wenn man sie vorher in Textdateien exportiert und an einem sicheren Ort abgespeichert hat. Die Vorgehensweise beim Exportieren und Importieren von Schlüsseln ist z.B. hier beschrieben.

Schritt 2: Zugang zu Amazon S3 einrichten

Um Daten bei Amazon S3 ablegen zu können, benötigen wir dort einen Account. (Dieser hat nichts mit einem etwaigen Affiliate-Account bei Amazon zu tun.) Wer also noch keinen solchen Zugang hat, richtet ihn sich hier ein. Dort wird eine Reihe von Produkten angeboten. Wir sind im Augenblick an S3 (Amazons Kürzel für Simple Storage Service) interessiert.

Nach dem Anlegen des Accounts und erfolgreichem Einloggen bitte auf den Navigationspunkt “Security Credentials” klicken. Dort müssen wir uns nun Zugangsschlüssel erstellen (Access Keys). Die nötigen Links seht Ihr in dem Screenshot unten. Anschließend bitte den Access Key und auch den Secret Access Key an einem sicheren Ort abspeichern bzw. notieren.

Wenn man Firefox benutzt, kann das Addon S3Fox hilfreich sein, um auf seinen S3-Account zuzugreifen. Mit S3Fox kann man sehr einfach seinen Cloud-Speicher bei Amazon einsehen und auch Dateien hoch- oder herunterladen. Wir benötigen es für unsere Backup-Routine nicht unbedingt, aber es ist ein nützliches Tool (nicht zuletzt zu Kontrollzwecken: Damit können wir später prüfen, ob unsere Backups bei Amazon angekommen sind).

Schritt 3: Duplicity installieren

Auch diesmal erfinden wir das Rad nicht neu, sondern bedienen uns eines Programms, das die Handarbeit beim Backup für uns erledigt. Es heißt Duplicity und liegt als Debian-Paket vor. Wir installieren es mit

apt-get install duplicity

Nachdem Duplicity installiert ist, legen wir uns ein Script an, um es zu steuern. Duplicity kann mit einer Vielzahl von Parametern arbeiten – bei Interesse hier nachzulesen. Wir benötigen nur einige davon.

Schritt 4: Unser Duplicity-Backup-Script

Das Script wird die folgenden Aufgaben erledigen:

• Sicherungen mit unserem GPG-Schlüssel verschlüsseln,
• Sicherungen in Buckets bei Amazon S3 ablegen (Buckets = wörtlich “Eimer”, entspricht Verzeichnissen),
• Täglich inkrementelle Sicherungen erzeugen,
• Nach 14 Tagen jeweils wieder eine vollständige Sicherung erzeugen,
• Backups entfernen, die älter sind als ein Monat.

All diese Einstellungen können im Script bei Bedarf angepasst werden.

Nun im Editor Eures Vertrauens eine neue Datei mit folgendem Inhalt erzeugen:

#!/bin/sh
export PASSPHRASE=DEINE-GPG-PASSPHRASE
export AWS_ACCESS_KEY_ID=DEIN-AMAZON-ACCESS-KEY
export AWS_SECRET_ACCESS_KEY=DEIN-AMAZON-SECRET-KEY

# Backups älter als 1 Monat löschen
duplicity remove-older-than 1M --encrypt-key=DEIN-GPG-KEY --sign-key=DEIN-GPG-KEY s3+http://BUCKETNAME

# Das normale Backup erzeugen
# Wird als Voll-Backup ausgeführt, wenn das letzte Voll-Backup länger als 14 Tage her ist
duplicity --full-if-older-than 14D --encrypt-key=DEIN-GPG-KEY --sign-key=DEIN-GPG-KEY /ZU/SICHERNDES/VERZEICHNIS/ s3+http://BUCKETNAME

export PASSPHRASE=
export AWS_ACCESS_KEY_ID=
export AWS_SECRET_ACCESS_KEY=

Die Zeilen nach dem Muster

duplicity remove-older-than …

und

duplicity --full-if-older-than 14D …

können durchaus mehrfach eingefügt werden, wenn man mehrere Verzeichnisstrukturen auf einen Rutsch sichern will. Hierbei immer auch den BUCKETNAME abändern. (Wenn ein Bucket übrigens noch nicht existiert, wird er bei Amazon automatisch angelegt.)

Einige der Angaben wie GPG-Key, GPG-Passphrase und Amazon-Keys müsst Ihr an den entsprechenden Stellen, die mit GROSSBUCHSTABEN markiert sind, einfügen.

Jetzt kann das Script gespeichert werden, z.B. als s3backup.sh, und mit Rechten am besten nur für den Root-User ausgestattet werden. Anschließend das Script ausführen. Wenn alles gut gegangen ist, könnt Ihr in S3Fox jetzt Eure verschlüsselten Dateien bewundern, die inzwischen auf den Amazon-Servern angekommen sind.

Hinweis: Kommt es beim Ausführen des Scripts zu einer Fehlermeldung

Boto backend needs version 0.9d or later

… dann fehlt auf Eurem Server eine Python-Library, die für die Kommunikation mit Amazon S3 zuständig ist.

(Liebt Ihr nicht auch aussagekräftige Fehlermeldungen mit klaren Handlungsanweisungen? Ich musste erstmal eine Weile googeln, bis ich die Ursache ermittelt hatte.)

Diese Library trägt den wunderbaren Namen python-boto und muss dann mit

apt-get install python-boto

nachinstalliert werden.

Anschließend sollte das Script funktionieren, falls alle Angaben richtig gesetzt sind.

Und keine Panik, wenn es einen Moment dauert – je nach Umfang der zu sichernden Verzeichnisse ist es unter Umständen einige Minuten beschäftigt.

Schritt 5: Das Rücksicherungs-Script

Kein Backup ist auch nur einen Schuss Pulver wert, wenn man es nicht wiederherstellen kann. Deswegen gehört zu unserem Setup natürlich auch ein Restore-Script, mit dem man einzelne Dateien oder auch ganze Verzeichnisse aus dem Amazon-Backup zurückholen kann, wenn einmal die Katastrophe eingetreten ist.

Es ist sehr wichtig, dass das Restore-Script nicht nur angelegt wird, sondern dass Ihr anschließend auch sofort testet, ob es funktioniert. Wenn sich einmal herausstellt, dass Ihr eine Datei aus dem Backup unbedingt benötigt, aber im Katastrophenfall wegen irgendwelcher Fehler die Rücksicherung nicht funktioniert, ist das ebenso, als hättet Ihr gar kein Backup!

Also wieder eine Datei anlegen – ich nenne sie s3restore.sh:

#!/bin/sh
export PASSPHRASE=DEINE-GPG-PASSPHRASE
export AWS_ACCESS_KEY_ID=DEIN-AMAZON-ACCESS-KEY
export AWS_SECRET_ACCESS_KEY=DEIN-AMAZON-SECRET-KEY

## Es gibt zwei Möglichkeiten zum Rücksichern. Die benötigte Option gezielt aktivieren durch Entfernen des Kommentarzeichens.
## Die Angaben müssen vor Ausführen des Scripts durch Dich angepasst werden.
## (Um das Backup komplett wiederherzustellen, lösche den Parameter --file-to-restore DATEINAME)

# Einzelne Datei wiederherstellen
# Die Angabe des Dateinamens ist zweimal erforderlich: einmal nach --file-to-restore und einmal als Angabe des Wiederherstellungsziels.
# Letzteres kann auch unterschiedlich lauten.
# Dateiname und Pfad sind relativ zum gesicherten Verzeichnis im Backup-Script (d.h. /ZU/SICHERNDES/VERZEICHNIS/test wird hier zu test).
#duplicity --file-to-restore DATEINAME s3+http://BUCKETNAME /DATEI/DIE/GESCHRIEBEN/WERDEN/SOLL --encrypt-key=DEIN-GPG-KEY --sign-key=DEIN-GPG-KEY

# Einzelne Datei von einem bestimmten Tag wiederherstellen – Beispiel hier von vor 4 Tagen
# Auch hier ist der Dateiname wieder zweimal erforderlich
#duplicity -t4D --file-to-restore DATEINAME s3+http://BUCKETNAME /DATEI/DIE/GESCHRIEBEN/WERDEN/SOLL --encrypt-key=DEIN-GPG-KEY --sign-key=DEIN-GPG-KEY

export PASSPHRASE=
export AWS_ACCESS_KEY_ID=
export AWS_SECRET_ACCESS_KEY=

Auch hier müssen wieder wie oben die Angaben wie GPG-Key, GPG-Passphrase und Amazon-Keys an den entsprechenden Stellen, die mit GROSSBUCHSTABEN markiert sind, eingefügt werden.

Die zwei Befehle, die duplicity zum Rücksichern von Dateien veranlassen können, sind hier aus Sicherheitsgründen auskommentiert, damit ein versehentlicher Aufruf des Scripts nicht zur Katastrophe führt. Um tatsächlich ein Restore zu machen, muss der gewünschte Befehl durch Entfernen des #-Zeichens aktiviert werden, und entsprechende Angaben zum Dateinamen gemacht werden.

Um das Rücksicherungs-Script zu testen, können wir nun z.B. probehalber eine bestimmte Datei aus unserem Amazon-Backup wiederholen.
Dazu beispielhaft folgende Annahmen:

• Wir betreiben im Verzeichnis /var/www/meinedomain.de/htdocs/ ein obskures CMS namens Joomla, dessen Datei index.php wir aus dem Backup wiederherstellen wollen.
• Wir haben als Sicherungs-Verzeichnis im Backup-Script “/var/www” angegeben.
• Wir sichern in den Amazon-Bucket “webroot“.
• Wir wollen die produktive Datei index.php im Joomla-Verzeichnis nicht einfach mit der Sicherungskopie aus dem Amazon-Backup überschreiben, sondern die Datei an einem anderen Ort wiederherstellen, um zu prüfen, ob die Restore-Routine richtig arbeitet.

Dazu tragen wir z.B. folgendes in das Restore-Script ein:

duplicity --file-to-restore meinedomain.de/htdocs/index.php s3+http://webroot /tmp/test.php --encrypt-key=DEIN-GPG-KEY --sign-key=DEIN-GPG-KEY

Noch den GPG-Key ersetzen, und dann kann das Script testweise gestartet werden. Wenn alles gut verlaufen ist, findet sich die wiederhergestellte Datei unter /tmp/test.php.

Schritt 6 – Datenbanken sichern

Wie man die Sicherung der Datenbanken automatisieren kann, habe ich im letzten Artikel bereits beschrieben. Wenn wir wollen, dass die aktuellen Datenbank-Dumps (die in meinem Beispiel in /var/cache/mysqlbackup/latest liegen) mit nach Amazon S3 gesichert werden, müssen wir in unser Script s3backup.sh nur an den passenden Stellen folgende Zeilen zusätzlich eintragen:

duplicity remove-older-than 1M --encrypt-key=DEIN-GPG-KEY --sign-key=DEIN-GPG-KEY s3+http://BUCKETNAME-FÜR-MYSQL

und

duplicity --full-if-older-than 14D --encrypt-key=DEIN-GPG-KEY --sign-key=DEIN-GPG-KEY /var/cache/mysqlbackup/latest/ s3+http://BUCKETNAME-FÜR-MYSQL

Schritt 7 – Alles automatisieren

Im letzten Artikel hatten wir zum Erzeugen der Datenbank-Dumps bereits einen Cronjob mit folgendem Inhalt angelegt:

30 3    * * *          root     /pfad/zu/automysqlbackup.sh

Nun können wir einen weiteren Cronjob anlegen, der eine halbe Stunde später das Script s3backup.sh aufruft:

0 4    * * *          root     /pfad/zu/s3backup.sh > /var/log/s3backup.log

Damit sollte alles erledigt sein, und wir können am nächsten Tag vermutlich beruhigt in die Logfiles schauen.

Troubleshooting

Es gibt einige Stellen, an denen man mit diesem Setup Fehler machen kann. Einige Hinweise dazu:

• Testet jeden Schritt einzeln und schaut in die Error-Logs des Servers. Klappt die Verschlüsselung? Könnt Ihr Euch zu Amazon S3 verbinden? Funktioniert Duplicity? Und klappt das Ganze auch als Cronjob?
• Falls es mit der Verschlüsselung Probleme gibt, gehören die GPG-Schlüssel demselben User, der das Script ausführt?
• GPG-Schlüssel, Passphrase, Amazon-Keys und Amazon-Bucketnamen müssen an einigen Stellen angegeben werden. Notiert sie Euch an einem sicheren Ort und prüft mehrmals, ob Ihr sie genau richtig eingegeben habt.

Fazit

Nun haben wir ein ziemlich robustes Backup-System im Einsatz. Alle gewünschten Dateien werden täglich in verschlüsselter Form auf eine hochverfügbare Cloud-Infrastruktur kopiert.

Einen problematischen Aspekt gibt es dabei: Die GPG-Passphrase ist in den Scripten auf dem Server im Klartext abgespeichert. Damit hätte jemand, der sich Zugang zu den Scripten verschafft, die Möglichkeit, die Backups zu löschen. Wenn jemand eine Möglichkeit kennt, hier Abhilfe zu schaffen, wäre es toll.