Zunehmend mehr Linux-Server oder auf Linux basierende virtual Appliances etablieren sich in den Infrastrukturen der Unternehmen. Die Administratoren stehen nun vor dem Problem, wie sie diese Systeme in ihr Backup-Konzept eingliedern.

Max Lessel

Eigentlich lässt sich ein Linux-System viel einfacher sichern, als ein Windows-Server. Selbst eine startfähige Systemsicherung kommt hier ohne komplexe Image-Backup- Tools aus, prinzipiell reicht ein File-Backup. Das System ist lange nicht so eng mit seiner Platte verheiratet, wie dies bei Windows der Fall ist. Eine komplette Systeminstanz ließe sich mit geringen Modifikationen anstatt von einer physischen Platte auch auf einer NFS-Freigabe ohne lokale Platte starten. Doch es gibt nicht nur Vorteile. Gerade wenn es darum geht, laufende Dienste konsistent zu sichern, muss der Verwalter tiefer in die Trickkiste greifen. speicherguide.de stellt einige grundlegenden Tools und Verfahren für die Sicherung und Recovery von Linux-Servern vor.

Traditionelle Backup-Ansätze

Die Vorfahren aller heute üblichen Backup-Programme sind »CPIO« und »TAR«. Im Prinzip schreiben beide Tools einfach eine Auswahl an Dateien sequentiell auf ein Band oder in eine große Binärdatei. Beide erlauben Zuwachssicherungen und können einzelne Dateien extrahieren. Mit Linux-üblichen Bordmitteln wie »ssh« verknüpft, können diese Tools auch über das LAN auf Bandlaufwerke an anderen Servern sichern, ein Beispiel:
# tar cvf - /home/user1 | ssh root@tapeserver "cat > /dev/nst1"

Schreibt den Inhalt des lokalen Verzeichnisses /home/user1 auf das zweite Bandlaufwerk des Servers mit dem Namen »Tapeserver«. Der Umgang mit diesen Backup-Urgesteinen erscheint komplex, allerdings darf man dabei eins nicht vergessen: Diese Tools sind sehr alt, was bedeutet, dass man heute unter Linux damit Bänder wieder einlesen kann, die in den 80er Jahren mit Tar unter DOS oder Unix geschrieben wurden. Vorausgesetzt man findet noch die passenden Laufwerke und die Magnetisierung in den Bändern reicht noch aus.

Ein ebenfalls beliebtes und zeitgemäßes Sicherungstool unter Linux ist »rsync«. Rsync vergleicht Quell- und Zielverzeichnisse und kopiert dann nur die geänderten Dateien. Rsync kann dabei Kompression einsetzen und läuft auch als eigener Netzwerkdienst mit privatem TCP-Port. Rsync lässt sich in kurzen Intervallen über den System-Dämon »cron« starten und realisiert damit eine »Near Continuous Backup«-Strategie. Dank einem effizienten LAN-Protokoll und der Option für Komprimierung eignet sich Rsync ebenso gut dazu, Backup-Daten über WAN-Leitungen zu schieben.

Bacula liefert versierten Linux-Anwendern sehr umfangreiche LAN-Backup-Funktionen. Die Open-Source-Netzwerk-Backup-Lösung fordert jedoch viel Linux-Wissen da die vielen verteilten Module in erster Linie über textbasierte Konfigurationsdateien gesteuert werden. Etwas anwenderfreundlicher stellt sich das kommerzielle Backup-Tool Arkeia dar, welches auch heterogene Umgebungen mit Linux und Windows-Systemen sichert.

Snapshots

Snapshots frieren den Zustand des Dateisystems zu einem Zeitpunkt ein um damit:

• Einzelne Dateien in einem früheren Stadium zurückzuholen,
• das komplette Dateisystem auf den Sicherungspunkt wiederherzustellen oder
• um diesen Zustand wegzusichern, ohne das Live-Dateisystem zu behelligen.

Snapshots liefern aber nur brauchbare Abbilder, wenn das Dateisystem und die darauf laufenden Applikationen sich mit dem Snapshot-Mechanismus koordinieren. Erzeugt ein Snapshot Abbilder von Dateien, die während des Snaps zum Schreiben geöffnet waren, sind diese Files auf dem Snapshot unbrauchbar und inkonsistent. Und genau hier wird es bei Linux etwas komplex.

Windows nutzt den »Volume Shadow Service«, in den sich auch Anwendungen wie Exchange oder SQL-Server einbinden lassen. Wenn ein Backup-Agent via VSS einen Snapshot erstellen will, warnt der VSS-Dienst die angebundenen Applikationen über Ihren Treiber vor. Der SQL- oder Exchange-Server kann vor dem eigentlichen Auslösen des Snapshots die Caches leeren und die zum Schreiben geöffneten Dateien schließen. Die Services halten den Betrieb kurz an, der Snapshot löst aus und im Anschluss laufen die Services weiter.

Linux kennt kein Snapshot-Kommunikations-Interface. Daher muss der Verwalter die aufgezählten Schritte manuell durchführen. Zudem gibt es unter Linux mehrere Ebenen, an welchen sich Snapshots erstellen lassen.

Der Linux »Logical Volume Manager« (LVM2) verwaltet logische Laufwerke, ohne dabei direkt von den darunter liegenden Platten abhängig zu sein. Der LVM2 kann Laufwerke im Betrieb erweitern und diese dabei auch über mehrere Platten spannen. Zudem erlaubt der LVM Snapshots. Da das Abbild auf Volume-, also auf Partitionsebene abläuft, funktioniert er unabhängig vom darauf laufenden Dateisystem. Das schafft Flexibilität, bringt aber noch mehr Aufwand hinzu.

Der Ablauf eines konsistenten Snapshots unter Linux muss daher wie folgt verlaufen:

• Applikationen dazu bringen, alle im RAM gepufferten Daten auf Platte zu schreiben und die zum Schreiben geöffneten Dateien zu schließen.
• Das Dateisystem dazu bringen, den kompletten Dateisystem-Cache auf die Platte zu schreiben.
• Den Snapshot auslösen.

Eine der populärsten Applikationen auf Linux-Servern ist die MySQL-Datenbank. Der Ablauf eines Snapshots sieht hier schematisch so aus:

• MySQL select database
• MySQL Flush tables with Read lock
• sync Dateisystem, auf dem die MySQL-Datenbank liegt
• LVM snapshot
• MySQL unlock tables
• mount snapshot
• Sichern aller Daten auf dem Snapshot (z.B. via Rsync)
• unmount snapshot
• delete snapshot

Neuere Dateisysteme wie Oracles »BTRFS« oder Suns »ZFS« integrieren Dateisystem und Volume-Manager in einem. Dort lässt sich der Snapshot direkt über das Dateisystem erledigen.

Integration der Snapshots in Backup-Tools

Programme wie CA »ARCserve« oder Symantec »Backup Exec« liefern Agenten für Linux mit. Diese können zwar die Dateien aus Linux-Servern sichern, kümmern sich jedoch nicht automatisch um die Konsistenz. Die meisten kommerziellen Agenten offerieren daher Skript-Schnittstellen um Routinen wie die eben erwähnte anzustoßen. Für konsistente Sicherungen empfiehlt es sich hier, den Backup-Agenten nur die Dateien aus einem Snapshot sichern zu lassen, der nach obigem Muster erstellt wurde. Dann gibt es keine Open-File-Probleme, welche der Backup-Agent selbst gar nicht lösen kann.

Ähnliches gilt für Virtuelle Maschinen, wenn das Backup über einen VM-Snapshot erfolgt. Auch hier offerieren VM-Utilitys wie die VMware-Tools eine Skript-Schnittstelle, um innerhalb der VM Applikationen und Dateisystem auf den VM-Snapshot vorzubereiten (Prä-Snapshot-Skript) und nach dem erfolgten Snapshot weiter laufen zu lassen (Post-Snapshot-Skript)

Recovery

Das Mount-Konzept unter Linux erlaubt es, einzelne Dateisysteme im laufenden Betrieb ein oder auszuhängen, so lange sich darauf keine offenen Dateien befinden. Es empfiehlt sich daher, die Daten einzelner Serverdienste auf getrennten Dateisystemen abzulegen. So lassen sich Daten einzelner Dienste einfacher wiederherstellen. Müssen Daten des Webservers zurückgelesen werden, reicht es dann, den Webserver kurz anzuhalten während die Datenbank jedoch weiter läuft.

Ein wesentlicher Vorteil von Linux ist, dass sich eine vollständige Distribution mit allen nur erdenklichen Tools von einer CD starten lässt. Eine Bare-Metal-Recovery-CD mit Netzwerkzugang und Restore-Tools ist daher schnell erstellt. In Netzwerken mit mehreren physischen oder virtuellen Linux-Systemen kann der Administrator auf den umständlichen Weg der CD verzichten. Mit wenigen Handgriffen lässt sich eine Image erstellen, welches via DHCP/PXE startet und sich so für jeden physischen oder virtuellen PC eignet, ohne eine CD irgendwo einlegen oder mounten zu müssen.

Boot to Backup

Da Linux bei der Auswahl des Startweges nicht pingelig ist, kann der Verwalter mit wenigen Tricks einen Server mit Plattenausfall Diskless starten, wobei er direkt auf das Backup seiner Dateisysteme zugreift. Das Backup-Konzept sichert in diesem Fall die Daten des Servers via Rsync auf einen Backup-Host, der die Sicherungsverzeichnisse per NFS freigeben kann. Über eine modifizierte und den PXE-Dienst kann der Server seine Produktivumgebung dann auch von den NFS-Freigaben des Backups starten. Dazu ist es erforderlich, dass der Verwalter eine modifizierte Version der »initrd« des jeweiligen Servers generiert und sichert, welche das Root-Dateisystem auf einer NFS-Freigabe mounten kann.

Bare-Metal-Prozedur

Ein Bare-Metal-Recovery eines Linux-Servers läuft nach einem sehr simplen Schema ab:

• Live-System von CD oder PXE starten
• Auf der (neuen) Platte die Dateisysteme anlegen, wobei die Aufteilung und Größen der Partitionen/Volumes nicht dem Original entsprechen müssen.
• Rücksicherung der Dateisysteme
• Anpassen von /etc/fstab an die neue Dateisystemaufteilung
• Installation des Bootloaders (i.d.R grub)
• Neustart ins wieder hergestellte System.

Fazit

Linux ist sehr flexibel bei Backup und Recovery. Speziell die Wiederherstellung eines Systems geht sehr einfach und zügig vonstatten. Allerdings muss der Administrator mit Skripten arbeiten, um Daten applikationskonsistent sichern zu können.