Webserver-Backup für Dummies 1: Lokales Backup

Heute geht es um ein ausgesprochen lästiges Thema. Dies ist die dunkle Seite des Webmaster-Daseins. Das unkreative Pflichtprogramm. Schrecklich, im Ernst.

Backups sind ja bekanntlich was für Feiglinge. Aber diejenigen unter uns, die einen Webserver betreiben, kennen vielleicht das Gefühl, das einen beschleicht, wenn die Kiste auf einmal nicht mehr erreichbar ist:

Ups. Ob nur der Apache abgestürzt ist? Oder ist es etwas Schlimmeres? Hat vielleicht das Script, das ich vorgestern installiert habe, Fürchterliches angerichtet? Oder ist die Festplatte / das Mainboard / eine andere wichtige Komponente abgeraucht?

Herzschlag und Körpertemperatur steigen. Adrenalin wird ausgeschüttet. Wir gehen nervös auf und ab. Die beste Ehefrau von allen beginnt zu fragen, ob alles in Ordnung ist.

Irgendwann hat dann der Hosting-Provider die Maschine gebootet, die Website ist wieder da, und wir beruhigen uns allmählich.

Dass der letzte Zeitpunkt, an dem wir alles per FTP runtergesichert haben, vielleicht schon die eine oder andere Woche her ist, rückt erst einmal wieder in den Hintergrund, und wir sagen uns, na klar müssen wir uns dann mal bald um eine gute Backup-Routine kümmern. Aber da im Augenblick erstmal wieder alles funktioniert, hat das ja noch einen Moment Zeit. Und so lehnen wir uns wieder zurück – bis zum nächsten Adrenalinschub.

So, ihr Prokrastinatoren dieser Welt. Das ist unverantwortlich. Und ihr wisst es.

Shared Hosting

Wer auf einem Shared-Hosting-Account unterwegs ist, kann sich schlimmstenfalls nicht auf ein providerseitiges Backup verlassen. Wer die Möglichkeit hat, über eine Administrations-Oberfläche wie z.B. cPanel selbst Backups zu erstellen, sollte das tun – und sich die Backups in regelmäßigen Abständen herunterladen. Ansonsten eben per Handarbeit mit MySQLDumper und FTP. Das deckt bei Billighosting dann auch schon das Spektrum der Möglichkeiten ab. Ja, ihr Shared-Hosting-Kunden müsst euch zwingen, immer wieder diese lästige Aufgabe zu erledigen.

Der eigene Root-Server

Wer aber einen eigenen Server (oder auch einen VPS) mit Root-Zugriff betreibt, dem stehen weitreichende Alternativen zur Automatisierung von Backups offen. Und wer das nicht nutzt, ist selbst schuld. Vor allem, wenn mehrere Websites (und vielleicht sogar Kunden-Websites) auf dem Server gehostet werden. Aber es ist nicht wirklich schwierig. Das Root-Dasein bringt viele wunderbare Vorteile mit sich, und die werden wir nutzen. Dummerweise stößt man oft beim Recherchieren auf lauter Geek-Speak-Howtos, von denen man keine Ahnung hat, wie man sie für die eigene Situation konkret umsetzen kann.

Also genug der Vorrede – das hier heißt schließlich Klartext – und direkt zur konkreten Nutzung. Im ersten Schritt beschreibe ich, wie ich auf Root-Servern mit Debian vollautomatisch Backups wichtiger Dateien und der MySQL-Datenbanken in einem separaten Bereich auf dem Server anlege. Der zweite Teil des Artikels wird sich dann mit der weiteren Verarztung dieser Backups beschäftigen.

Die Sicherungsstrategie geht dabei darüber hinaus, immer nur einen einzigen aktuellen Schnappschuss anzulegen und vorzuhalten. Vielleicht benötigt man ja noch einmal die vorvorletzte Version eines Backups, weil man sich eine Installation total verhunzt hat und das erst ein paar Tage später bemerkt. Also werden wir immer mehrere Sicherungen in chronologisch absteigender Reihenfolge anlegen.

Und für diejenigen, die wie ich in einer PHP/MySQL-Umgebung unterwegs sind, gilt es beim Thema Backup immer zwei Dinge zu beachten: Es müssen sowohl die Dateien im Webroot als auch die MySQL-Datenbank(en) gesichert werden. Das eine ist ohne das andere herzlich wenig wert.

Unsere Sicherungsroutine umfasst also zwei Bereiche, die gleichermaßen berücksichtigt werden müssen. Wir beginnen mit den Datenbanken.

MySQL-Datenbanken sichern

Den meisten Admins dürfte der Befehl mysqldump bekannt sein. Mit ihm kann man den Inhalt von Datenbanken wegsichern. Um unsere Strategie mit mehreren chronologischen Backups umzusetzen, müssten wir nun eine gewisse Logik um den Aufruf von mysqldump herumstricken – oder aber wir bedienen uns bei jemandem, der sich genau diese Mühe schon gemacht hat und sein Script dankenswerterweise der Öffentlichkeit zur Verfügung stellt. Die Königslösung heißt AutoMySQLBackup und bietet alles, was wir brauchen. Mit diesem Script können alle Datenbanken auf dem Server gesichert und in beliebig definierbaren Vergangenheitsintervallen vorgehalten werden. Das Script kümmert sich außerdem um das automatische Löschen alter Dumps.

Bei mir kommt das Script unter dem Namen automysqlbackup.sh in ein beliebiges Verzeichnis (z.B. /home) und wird mit chmod ausführbar gemacht. Die notwendige Konfiguration kann direkt im Script erfolgen und ist wegen ausgiebiger Kommentierung weitgehend selbsterklärend.

Zwei Optionen sind für die Backup-Strategie wichtig. Zum einen muss bestimmt werden, wo die Datenbank-Dumps angelegt werden. Zum Beispiel:

BACKUPDIR=”/var/cache/mysqlbackup”

Außerdem empfiehlt es sich unbedingt, das jeweils letzte Backup nochmal gesondert vorzuhalten. Hierfür setzen wir

LATEST=yes

Anschließend kann man das Script mit

./automysqlbackup.sh

testweise ausführen. Je nach Größe der Datenbanken benötigt es unter Umständen eine kleine Weile. Anschließend kann das Ergebnis in /var/cache/mysqlbackup bewundert werden.

Hat alles geklappt? Glückwunsch! Dann ist es Zeit, dem Server zu sagen, dass er das Script bitte automatisch auszuführen hat. Hierfür legen wir in /etc/cron.d eine kleine Datei mit folgendem Inhalt ab:

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

Damit wird jeden Tag um 03:30 Uhr das Script mit Root-Rechten ausgeführt. Somit ist die Sicherung der MySQL-Datenbanken automatisiert, und wir können zum zweiten Schritt, dem Sichern der Dateien, übergehen.

Dateien sichern

Wichtige Dateien lege ich ebenfalls zunächst auf dem Server selbst ab. Das ist ungemein hilfreich, wenn man mal schnell eine Datei in der gestrigen oder vorgestrigen Version noch einmal benötigt: Finden, zurückkopieren, fertig.

Auch hier gibt es Unterstützung beim tageweisen Sichern der Dateien, diesmal in Form eines Debian-Pakets namens rsnapshot. Also fix installieren mit:

apt-get install rsnapshot

Unter /etc/rsnapshot.conf findet sich nun die Konfigurationsdatei, in der wieder einige Einstellungen vorzunehmen sind. Insbesondere sind das die Angabe des Zielverzeichnisses:

snapshot_root   /var/cache/rsnapshot

und der vorzuhaltenden Sicherungsintervalle:

interval        daily   7
interval        weekly  4
interval        monthly 3

sowie die Angabe darüber, welche Verzeichnisse eigentlich gesichert werden sollen. Ich sichere das home-Verzeichnis, das etc-Verzeichnis wegen der Konfigurationen der Programme, die auf dem Server laufen, und das gesamte Webroot:

# LOCALHOST
backup  /home/        localhost/
backup  /etc/         localhost/
backup  /var/www/     localhost/

rsnapshot legt inkrementelle Backups an. Um keinen Speicherplatz zu verschwenden, werden unveränderte Dateien nicht mehrfach abgelegt, sondern mit Hardlinks referenziert. Die jeweils aktuellste Version eines Backups findet sich dann z.B. unter /var/cache/rsnapshot/daily.0/localhost.

Alles konfiguriert? Dann testen mit:

rsnapshot daily

Wenn alles zufriedenstellend verlaufen ist, bekommt auch rsnapshot seinen eigenen Cronjob mittels

30 3    * * *           root    /usr/bin/rsnapshot daily
0  3    * * 1           root    /usr/bin/rsnapshot weekly
30 2    1 * *           root    /usr/bin/rsnapshot monthly

Damit haben wir die wesentlichen Sicherungen automatisiert und können uns, wenn wir es bis hierhin geschafft haben, schon mal kräftig auf die Schulter klopfen.

Onsite-Backups vs. Offsite-Backups

Aber Klaus, höre ich euch rufen, das ist doch noch kein richtiges Backup! Was, wenn der Server eines Tages, der Himmel möge es verhüten, komplett zu Staub zerfällt?

Vollkommen korrekt. Im Moment liegt alles noch direkt auf der Maschine, die wir sichern wollen. Gut für schnelle Korrekturen, wenn wir mal etwas verbockt haben und einen früheren Stand wiederherstellen wollen. Solange der Server ordnungsgemäß läuft. Aber nicht gut für den eigentlichen Katastrophenfall, denn da brauchen wir die Backups natürlich möglichst im Safe oder an einem anderen Ort außerhalb des Servers – offsite eben.

Höhere Sicherheit könnten nun z.B. regelmäßige Downloads der erzeugten Backups bieten. Wer zuhause auch nochmal eine Linux-Möhre stehen hat, kann das elegant mit rsync erledigen. Und unter Windows kann man mit einem automatisierbaren FTP-Programm in Verbindung mit dem Task-Manager nächtlich die aktuellsten Sicherungen herunterladen. Filezilla eignet sich dafür allerdings leider nicht; es besteht auf interaktiver Bedienung.

Aber der Teufel ist ja bekanntlich ein Eichhörnchen. (Wer mir übrigens die Herkunft dieser Redewendung schlüssig erklären kann, bekommt einen Dofollow-Backlink von mir.) Wie es Murphy will, tritt der K-Fall gerne auch mal dann ein, wenn wir gerade unterwegs sind und keinen Zugriff auf die heimischen Backups haben.

Aber Informationsarbeiter, digitale Nomaden und kluge Serverbetreiber sorgen für diese Situation vor. Sie gehen in die Cloud. Und das wird, bevor jetzt gleich der Buzzword-Alarm losgeht, Inhalt des zweiten Teils sein. Für heute reicht’s – wer es bis hierhin geschafft hat, hat schon beste Voraussetzungen. Bis demnächst auf einem Debian-Server eures Vertrauens.