Niemand will Backup, alle wollen Restore!

Wie versprochen die „rundum glücklich“-Lösung für das Backup. Ein grundlegendes Problem ist das Backup im laufenden Betrieb. Noch während das Backup läuft, verändern laufende Prozesse Dateien. Im Allgemeinen ist die /var-Partition und im Besonderen sind Datenbanken und Mailqueues problematisch. Man kann sich nie sicher sein, ob der Stand im Backup wirklich konsistent ist.

Es gibt verschiedene Ansätze dem Problem Herr zu werden. Eine Datenbank könnte man in ein SQL-File dumpen, der Mailserver könnte kurz angehalten werden um die Mailqueue zu sichern. Das sind jedoch alles nur 99%-Lösungen. Eigentlich müsste man das System für den Zeitpunkt des Backups komplett einfrieren, das Backup durchführen und es danach weiterlaufen lassen.

Snapshots implementieren diese Technik und verhindern so eine Downtime des betroffenen Services. Zunächst in Datenbanken wie z.B. Oracle populär, finden sich Snapshots jetzt auch in Dateisystemen (LVM, Windows Vista Shadow Copies). Der Snapshot selbst ist eine atomare Aktion, die lediglich den Snapshot-Zeitpunkt (t) festhält. Alle nach diesem Zeitpunkt (t+x) geschriebenen Blöcke werden separat gespeichert, so dass nun in aller Ruhe alle Blöcke des Zeitpunkt (t) ins Backup wandern können. Ist das Backup beendet, kann der Snapshot verworfen werden.


Möchte man LVM-Snapshots nutzen, benötigt man noch etwas freien Platz in einer Volume Group. Dieser freie Speicher wird dafür verwendet, Änderungen am Dateisystem nach dem Zeitpunkt (t) zu speichern. Man sollte diesen Platz ausreichend dimensionieren, denn läuft das Snapshot-Volume voll, wird der Snapshot ungültig. Eine Faustregel sagt 15 bis 20% der Größe des Originaldateisystems sind angemessen. Wenn wir also einen Snapshot von einem 10GB Volume anlegen wollen, sollte der Snapshot 2GB groß sein. Das bedeutet, es können 2GB an Änderungen in das Dateisystem geschrieben werden, bevor der Snapshot ungültig wird. Da das Backup relativ schnell durchläuft, sind wir mit der Faustregel auf der sicheren Seite.

Snapshots erstellen

Ok, genug Theorie, wir legen also von den Volumes /var, /home und /usr einen Snapshot an:

Zur Kontrolle schauen wir mal mit lvscan nach:

Die Snapshots können jetzt unter z.B. /mnt/lvm-backup gemountet werden.

Jetzt können wir uns unter /mnt/lvm-backup umsehen und davon überzeugen, dass alle Dateien da sind 😉 Wenn die Snapshots nicht mehr gebraucht werden, können sie wieder gelöscht werden:

Backup mit dar

Für das eigentliche Backup ist es dann schon fast egal, welches Tool verwendet wird. Tar ist der Klassiker und sicher eine gute Wahl. Ich bevorzuge allerdings dar, weil man damit sehr einfach inkrementelle Backups erstellen kann und die Unterstützung für Wechselmedien eingebaut ist. Wechselmedien wie DVDs haben wir bei dem Rootserver zwar nicht, es gibt jedoch FTP-Server, die nur Dateien bis zu einer Größe von 2GB unterstützen. Also wird das Backup in kleinere Slices gesplittet.

Falls dar dar noch nicht auf dem Server installiert ist, kann das jetzt nachgeholt werden:

Für das erstellen eines Backup-Scriptes empfehle ich wärmstens das DAR-Tutorial. Es macht wenig Sinn, die folgenden Scripte zu Copy&Pasten, wenn man sie nicht verstanden hat. Ok, Tutorial gelesen und verstanden? Fein, dann kann es ja losgehen.

Durch das Setup unseres Servers müssen wir etwas umdenken: /home, /usr und /var können mittels der LVM-Snapshot Technik gesichert werden, das Root-Dateisystem (bin, boot, etc, lib, opt, tmp) liegt jedoch nicht auf einem LVM-Volume und muss „klassisch“ gesichert werden. Wer sein Root auf einem LVM hat, ist jetzt fein raus. Da in den betroffenen Verzeichnissen eher statische Daten liegen, sollte das jedoch kein Problem sein.

Komplett-Backup der Root-Partition

Das Backup-Script dar-root-full-backup.sh für ein Full-Backup der Root-Partition sieht so aus:

Dank des DAR-Tutorials ist natürlich sofort klar, dass hier in Slices zu je 1GB gesichert wird. Verzeichnisse wie /proc und die LVM-Volums /home, /usr und /var werden vom Backup ausgeschlossen (-P).

Das Backup landet dann z.B. in /mnt/backup/2007-07-14_root-backup_full.1.dar.

Differentialbackup der Root-Partition

Das Backup-Script dar-root-diff-backup.sh für ein Differentialbackup der Root-Partition sieht so aus:

Der Einzeiler PREV=... sucht immer das jüngste Backup. Der Unterschied zum vorherigen Script ist lediglich der Parameter -A $PREV. Damit macht man DAR das vorhergehende Backup als Referenz bekannt. Jetzt werden nur noch die Unterschiede zum letzten Backup gesichert.

Vollständiges Backup der LVM-Partitionen

Das Backup-Script dar-homeusrvar-full-backup.sh für ein Full-Backup der LVM-Partitionen sieht so aus:

Das ist ein wenig mehr Magie. Vor dem Backup werden die Snapshots erstellt, nach dem Backup wieder weggeräumt. Da die Snapshots nach /mnt/lvm-backup gemountet werden, ist die Exclude-Liste relativ kurz.

Differentielles Backup der LVM-Partitionen

Das Backup-Script dar-homeusrvar-diff-backup.sh für ein Differentialbackup der LVM-Partitionen sieht so aus:

Ordnung halten

Die Backup-Scripte können jetzt via cron nachts aufgerufen werden. Zwei Zeilen in /etc/crontab genügen:

An jedem 1. des Monats läuft das Komplettbackup, an allen anderen Tagen das Differentialbackup. full-backup.sh ist lediglich ein Wrapper-Script und sieht so aus:

Das gleiche nochmal für’s Differentialbackup (diff-backup.sh):

Damit das Backup-Verzeichnis nicht voll läuft, müssen alte Backups gelöscht werden. Dafür legen wir unter /etc/cron.daily ein kleines Script delete_old_backups.sh an, das alle Dateien, die vor mehr als 32 Tagen erstellt wurden, löscht:

Fertig?

Nicht ganz. Zu jedem Backup gehört ein Restore. Am besten testet man das gleich vom Rescue-System aus. Zuerst werden die Volumes gemountet:

Ok, jetzt liegt das Backup unter /mnt/mnt/backup. Wir nehmen das letzte Full-Backup und spielen es nach /mnt/mnt/restore/

Das home/var/usr-Backup muss auch noch zurück gespielt werden:

So, das sollte es gewesen sein. Hoffen wir darauf, dass nie ein Backup zurückgespielt werden muss 😉

Lektüre

Lesetipps:

Zum vorherigen Teil: FTP-Backup: Speicherplatz nutzen »
Zum ersten Teil: Debian Etch auf einem Rootserver mit Raid-1 und LVM »

2 Antworten auf „Niemand will Backup, alle wollen Restore!“

  1. klasse anleitung 🙂

    es ist doch bestimmt auch möglich die ganze platte bei kleineren vms mit dd aus dem snapshot zu dumpen oder!?

    hast du das schonmal ausprobiert, wie sind da deine erfahrungen mit?

    meine vms sind in etwa 10G gross.

    gruss enzo

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.