Heimgeholt, gesichert: inkrementelle Backups mit rsync und rsnapshot erstellen

Regelmäßige Backups von Webseiten sind unverzichbar. Doch wenn man fünfzig TYPO3- oder WordPress-Webseiten auf verschiedensten Servern mit unterschiedlichen Eigenschaften regelmäßig und zuverlässig sichern möchte, steht man vor einer kleinen Herausforderung. Um es vorweg zu nehmen: Es gibt nicht eine Lösung, die überall funktioniert, sondern man muss sich genau anschauen, was die Server können und daran seine Backup-Strategie anpassen. Die nachfolgend dargestellte Lösung läuft auf etwas besseren Paketen oder Servern mit Shell-Zugang und rsync. In unserem Falle haben wir viele TYPO3-Webseiten auf Servern der Firma Mittwald liegen, weil uns dort der Service gefällt. Wieder andere Kunden haben Pakete oder Server bei Hetzner, 1und1, domainfactory, allInkl etc. Ich will nachfolgend beschreiben, wie man eine gute Backup-Strategie angehen kann, bei der Datenbanken- und File-Backups erstellt und auf einem lokalen Linux-Rechner gespeichert werden. Die nachfolgend dargestellte Lösung läuft auf etwas besseren Paketen oder Servern mit Shell-Zugang und rsync.

Backup auf Mittwald-Servern

Auf Mittwald(-TYPO3)-Servern gibt es keine Kundenübergreifende Instanz mit der es möglich ist alle Kunden zu sicher. Daher muss für jeden Kunden eine Backuplösung erstellt werden. Daher habe ich mich entschieden die Backups auf einem externen Backupserver (der Server auf dem die Backups gespeichert werden sollen) laufen zu lassen. Als Backupprogramm benutze ich rsnapshot, welches auf den jeweiligen Klienten (Webservern/Kunden) rsync voraussetzt. Dieses Programm kann bei jedem Kunden im Softwaremanager von Mittwald-Servern nachinstalliert werden.

SSH Login ohne Passwort

Um automatisierte Backups vom Backupserver auf den verschiedenen Kundenaccounts durchführen zu können ist es notwendig den Login-Prozess zu automatisieren, sprich sich ohne Passwort einloggen zu können. Zu diesem Zweck erlaubt es SSH sich via Schlüssel zu authentifizieren. Dazu muss zunächst ein Schlüsselpaar erzeugt werden. Hierzu folgenden Befehl auf dem Backupserver eingeben:

sudo ssh-keygen -t dsa

Damit werden eigene Schlüsselpaare erzeugt. Die Passphrase sollte leer sein, da sonst später beim Cronjob diese abgefragt wird. Es entstehen somit Dateien mit den Schlüsselpaaren: /root/.ssh/id_dsa und /root/.ssh/id_dsa.pub Die *.pub-Dateien können nun auf den Zielhost kopiert und dort an ~/.ssh/authorized_keys angehängt werden:

ssh-copy-id -i /root/.ssh/id_dsa.pub user@remote-system

Oder, wenn ssh-copy-id nicht vorhanden ist:

cat /root/.ssh/*.pub | ssh user@remote-system 'umask 077; cat >>.ssh/authorized_keys'

Jetzt sollte es möglich sein sich per

ssh user@remote-system

einzuloggen ohne ein Passwort einzugeben.

Backup mit rsnapshot

rsnapshot ist eine auf rsync basierte Backuplösung, die inkrementelle Backups erstellen kann. Dabei spielt es keine Rolle ob die Backups lokal oder remote durchgeführt werden. rsnapshot benutzt Hardlinks um Festplattenplatz und Bandbreite zu sparen.

rsync und rsnapshot installieren

Lauft auf dem Backupserver Ubuntu kann rsnapshot bequem über das Repository installiert werden:

sudo apt-get install rsnapshot, rsync

Zur manuellen Installation bitte hier nachlesen:http://www.rsnapshot.org/howto/1.2/rsnapshot-HOWTO.en.html#installation

rsnapshot konfigurieren

Zunächst muss die Konfigurationsdatei (/etc/rsnapshot.conf) angepasst werden. Die meisten Einstellungen sind für unsere Zwecke ok. Zunächst habe ich die Pfade angepasst:

snapshot_root		/home/undkonsorten/.snapshots/
cmd_cp			/bin/cp
cmd_rm			/bin/rm
cmd_rsync		/usr/bin/rsync
cmd_ssh			/usr/bin/ssh
cmd_logger		/usr/bin/logger
cmd_du			/usr/bin/du
cmd_rsnapshot_diff	/usr/bin/rsnapshot-diff

Dann habe ich aktiviert, das auch monatliche Snapshots angelegt werden.

interval	monthly	3

Jetzt wird eingestellt welche Server alle zu sichern sind:

backup	user@example1.com:/path/	example1.com/
backup	user@example2.com:/path/	example2.com/

Der letzte Eintrag example1.com/ bezeichnet den Ordner in dem lokal das Backup gespeichert werden soll. Für weiter Einstellungen bitte unter http://www.rsnapshot.org/howto/1.2/rsnapshot-HOWTO.en.html#configuration nachlesen. Wenn das Script per Cronjob ausgeführt wird, dann loggt sich der Backupserver per SSH auf die zu sichernden Rechner ein und startet das inkrementelle Backup, in diesem Beispiel jeden Montag, Mittwoch und Sonntag jeweils um 3:00 Uhr, Sonntags um 3:00 Uhr wird der wöchentliche Snapshot erstellt und jeden 1. im Monat um 3:00 Uhr der monatliche.

crontab -e
0 3 * * 1,3,7		/usr/bin/rsnapshot daily
0 3 * * 7		/usr/bin/rsnapshot weekly
0 3 1 * *		/usr/bin/rsnapshot monthly

Script-aufrufe auf dem zu sichernden Rechner

Eine weitere Interessante Möglichkeit von rsnapshot ist, das vor dem eigentlichen Backup Scripte oder Befehle ausgeführt werden können. Dies ist mit backup_script möglich. Ich benutze dies um Datenbankdumps zu erstellen bevor alle Dateien per rsync abgeholt werden. Dabei stehen zwei Möglichkeiten zu Verfügung. Die erste ist eine Befehl direkt per SSH an den Server zu schicken:

backup_script
/usr/bin/ssh user@example.com "mysqldump --user=USER --password=PASSWORD --host=HOST  --quote-names --opt --compress --ignore-table=database.table1 --ignore-table=database.table2 --ignore-table=database.table3 DATABASE | bzip2 > database.sql.bz2"	unused1/

wichtig sind hierbei die TABS:

backup_script {tab} befehl {tab} relatives Ziel

Dieses "relative Ziel" ist ein Pfad, der bei script aufrufen nicht benutzt aber benötigt wird, daher "unused1/" ;-) Die Option --ignore-table ist sehr praktisch gerade für Typo3 Seiten, da so nicht wirklich benötigte Tabellen ausgelassen werden (z.B. die cache Tabellen) können. Da diese oft sehr gross werden wird das Backup durch das auslassen schnell und kleiner. Dies sähe dann so aus:

--ignore-table=database.cache_extensions --ignore-table=database.cache_hash --ignore-table=database.cache_imagesizes --ignore-table=database.cache_md5params --ignore-table=database.cache_pages --ignore-table=database.cache_pagesection --ignore-table=database.cache_sys_dmail_stat --ignore-table=database.cache_typo3temp_log --ignore-table=database.index_config --ignore-table=database.index_debug --ignore-table=database.index_fulltext --ignore-table=database.index_grlist --ignore-table=database.index_phash --ignore-table=database.index_rel --ignore-table=database.index_section --ignore-table=database.index_stat_search --ignore-table=database.index_stat_word --ignore-table=database.index_words --ignore-table=database.tx_realurl_urlencodecache

Die zweite Möglichkeit ist ein Script auf dem Server aufzurufen:

backup_script	/usr/bin/ssh user@example.com "/backup/sqlbackup"	example.com/unused1/

In diesem Fall ist sqlbackup ein Backupscript mit allen nötigen Einstellungen. Ich benutze übrigens AutoMySQLBack. Welches rotierende snapshots von den Datenbanken legt. Ein volles Backup auf einem Server sieht dann bei mir so aus:

backup_script	/usr/bin/ssh user@example.com "/backup/sqlbackup"	example.com/unused1/
backup	user@example.com:/html/	example.com/
backup	user@example.com:/backup/dump/	example.com/
backup_script	/usr/bin/ssh user@example2.com "/backup/sqlbackup"	example2.com/unused1/
backup	user@example.com:/html/	example2.com/
backup	user@example.com:/backup/dump/	example2.com/

Dies liefert dann auf dem Backup-Server folgende Verzeichnisstruktur:

.snapshots/
|-- hourly.0
|   |-- example.com
|   |   |-- backup
|   |   |   `-- dump
|   |   |        |-- daily
|   |   |        |   `-- database
|   |   |        |       `-- dump.sql.bz2
|   |   |        |-- monthly
|   |   |        |-- weekly
|   |   `-- html
|   |-- unused1
|   `-- example2.com
|-- daily.X
|-- weekly.X
|-- monthly.X
..... usw.

So, ich wünsche Euch gut laufende Seiten und dass Ihr Eure Backups nicht zu oft herauskramen müsst. Ich bin gespannt auf Kritik, Anregungen, Tipps.