Linux System als BackupServer

Auf der sicheren Seite!
Chris Weber / Andreas Lindenblatt / Daniela Lindenblatt

Ein leidiges Problem aus der Praxis ist sicher das zentrale Erstellen von Backups. Für einzelne Rechner gibt es sehr gute Lösungen, aber wie sichert man Daten verteilt auf vier NT Servern über einen Tapechanger unter Linux ?



Backup?

Kennen Sie den ???
"Wollen Sie XYZ wirklich löschen ? [Ja/nein] "
Noch schnell ein [J] und ein [Return] hinterher und als Abschluß eine Menge Flüche.

Gut - oder eher nicht gut. Auf jeden Fall sollte man für solche Fälle ein Backup "in der Tasche" haben. Noch wichtiger ist dies, wenn sich dieser Fall bei einem Kunden abspielt (für dessen Netzwerk/Administration man verantwortlich ist).
Ein Kunde setzt immer voraus das man für jeden Fall vorbereitet ist und für jedes Problem ein Lösung aus dem Hut zaubert.

Naja - dafür ist man ja schließlich da :-)

So geschehen in einem der Netze die in unserer Obhut liegen. Der Teil des Netzes, welches es zu sichern gilt, baut sich so auf:

4 x NT 3.51 Server, angebunden an je einem 20 Port Cabeltron Switch (der das jeweilige Stockwerk speist). Die Switche kommunizieren untereinander über Glasfaserleitungen.
Diese Leitung dient als Backbone über alle Stockwerke bis hinab zum Keller, dort sitzt der zentrale Knoten des Ganzen in Form eines weiteren Switches.

Diese Installation ist noch recht neu, das Unternehmen hatte seinen Firmensitz vormals in einem kleineren Gebäude. Dort gab es zwischen den Teilnetzen keine Verbindung, also wurde in jedem der NT Server ein eigener DAT-Streamer verbaut.
Klar, für jeden der Server wurde 1x Backupsoftware benötigt. Diese Konfiguration hat sich auch recht gut geschlagen - bis vor ca. 5 Monaten. Da nämlich zeigten die DAT-Streamer langsam Alterserscheinungen. Normale Vorgehensweise wäre sicherlich der Austausch der defekten Geräte gewesen. Allerdings - man sollte sich die bisherige Arbeitsweise beim Backup vor Augen halten. Aufgrund der Firmenstruktur ist in jedem Stockwerk eine Person damit beauftragt, täglich das Band des jeweiligen Servers zu wechseln. Meist klappt das sehr gut, aber nach Murphy halt gerade dann nicht, wenn es nötig gewesen wäre. Mal wird das Band für den gestrigen Tag eingelegt, mal das für den morgigen Tag, mal überhaupt nicht gewechselt weil die betreffende Person im Urlaub, krank oder sonstwie verhindert ist und der Vertreter es schlicht vergessen hat. Nein, es kommt nicht oft vor, aber wenn alle Umstände zusammenspielen steht man mit veralteten Daten da.

Zentrale Sache

So wurde die Entscheidung getroffen, das Backup zu zentralisieren und anstelle von mehreren einzelnen DAT Laufwerken ein einziges mit genügend Kapazität anzuschaffen. Möglich war das ja nun, nach dem Umzug in ein neues Gebäude, der Neuaufteilung des Netzes und der Verfügbarkeit eines Glasfaser-Backbones. Die Wahl fiel auf einen 6-fach Tape-Wechsler bestückt mit fünf 12 Gigabyte Kassetten und einem Reinigungsband.
Wie im vorherigen Artikel (10/98, Migration von Novell nach Linux) boten wir wieder zwei Alternativen an.
Die erste - konventionelle - sah wiederum den Einsatz eines weiteren Windows NT mit entsprechender Backupsoftware vor. Das zweite Angebot wurde mit Linux als Betriebsystem für den Backupserver erstellt. Um das System unter NT laufen zu lassen, wäre eine Erweiterung der Lizenzen nötig gewesen, ebenso eine erweiterte Version der vorherigen Backupsoftware. Alle benötigten Lizenzen zusammen hätten den Preis einer Lösung unter Linux - inklusive der benötigten Hardware - bereits weit überschritten. Dieses Argument führte dann auch dazu, daß sich das Unternehmen zum Einsatz von Linux überzeugen ließ.
Als Rechnerhardware kam wieder mal unsere "Linux-Server-Standardlösung" :-) zum Einsatz. Allerdings waren wir in diesem Fall mit einem neuen Problem konfrontiert, nämlich:
welche Netzwerkkarte ? Auf den ersten Blick eigentlich kein Problem, auf den zweiten allerdings schon. Der Backupserver steht am zentralen Netzwerkknoten. An diesem kann man aber nur Lichtwellenleiter anschließen. Wir haben schlicht keine Netzwerkkarte gefunden die 1. LWL Anschluß besitzt und von der wir 2. sicher wissen, daß sie unter Linux läuft.
Schlußendlich wurde dann ein Umsetzer von/nach LWL/TP eingesetzt (neuerdings führt 3Com eine Netzwerkkarte mit LWL Anschluß auf der Basis der 3c9xx im Programm, wahrscheinlich funktioniert der aktuelle Linux-Treiber damit). Ansonsten, wie gehabt, SCSI Host von Adaptec, HardDisk von IBM, Board von ASUS, etc, pp.

Strategische Entscheidung

Die Backupstrategie sieht vor, pro Tag ein Band zu verwenden. Auf ein 12GB Band geht eine Menge 'drauf, zumal die Angabe 12GB sich auf das Bandvolumen (also ungepackt) bezieht. Viele Hersteller geben mit Vorliebe Bandkapazitäten bei Kompression von 2:1 an.
DAT-Streamer 24GB liest sich halt besser als DAT Streamer 12GB. So etwas kann zur Falle werden, denn schnell vergrößert sich der zu sichernde Datenbestand und kaum ein Unternehmen bringt Verständnis dafür auf das es nach 1,5 Jahren wieder in das gleiche Projekt investieren soll.

Bändchen wechsel Dich

Gut, alles kein Problem.... eh, da war doch was ???
Richtig. Bandauswahl für den entsprechenden Tag. Oder anders formuliert: Wie bestimmt man, welches Band aus dem sechsfach Lagerbehälter in den Schreibmechanismus befördert werden soll ? Die Dokumentation zum Streamer empfiehlt lapidar: Unter UNIX stellen Sie bitte am Wechsler Schalter X nach oben, Y nach unten usw. Dann wird ein Band voll geschrieben und automatisch das nächste Leerband in den Schreibmechanismus eingelegt. Das war nicht das, was wir uns vorgestellt hatten. Pro Tag ein Band sollte es sein, nicht Backups über verschiedene Bänder verteilt. Natürlich könnte man kann direkt am Gerät das einzulegende Band wählen, aber wir wollten Interaktionen mit dem System soweit wie möglich vermeiden.
In jeder Distribution findet sich "mt". Man verwendet es beispielsweise um Bänder vor und zurück zu spoolen, Bandmarken zu setzen oder Bänder zu löschen.
Leider eignet es sich nicht, um einen Wechsler zum Einlegen / Wechseln der Bänder zu bewegen. Eine Suche im Internet brachte aber doch noch ein passendes Tool zum Vorschein. Das Programm nennt sich "mtx" und erlaubt es, direkt auf das gewünschte Band zuzugreifen.
Zu finden ist es unter http://www.dandelion.com/Linux/

LUN oder nicht LUN?

Unverzichtbar ist die Unterstützung von mehreren LUN's durch den Kernel. Da diese SCSI Option sehr selten gebraucht wird, ist sie in allen uns bekannten Linuxdistributionen abgeschaltet. Das heißt also: neuen Kernel mit der entsprechenden Option im Treiber kompilieren und installieren, sonst geht's einfach nicht. Dieser letzte Punkt hat einiges Kopfzerbrechen bereitet.

Final Countdown

Nach Abschluß aller Vorbereitungen wurde das System jetzt installiert.
Auf den NT-Servern war noch die Nachinstallation von TCP/IP nötig, da der Zugriff via "NetBIOS über TCP/IP" erfolgt. Jeder NT Server bekam eine statische IP zugewiesen. Da das Netz weiterhin aus 4 Unternetzen bestehen soll, wurden diese IP's in verschiedene Teilnetze gelegt.
Nach Anpassung der Switche sind somit Zugriffe zwischen den Stockwerken nur noch über den Linux-Server im Keller möglich und ergo adminstrierbar.
Parallel dazu erfolgt eine Schritt-für-Schritt-Umstellung des gesamten Netzes von IPX nach TCP/IP - schließlich haben wir mit dem Linux-Server noch "Großes" vor.
Der Linux-Backup-Server soll zukünftig die Basis des Intranets in diesem Unternehmen bilden, denn die Sicherung der NT Server lastet den Rechner nicht gerade aus :-)

Überraschung...

Das Sichern der Datenbestände stellten wir uns so vor:
Im Trockentest funktionierte das auch hervorragend, beim endgültigen Einsatz allerdings nicht mehr. Eine der firmenspezifischen Softwarelösungen legt eine Unmenge an Einzeldateien an (>6000 in einem Verzeichnis). Die ursprünglich eingesetzte Software (BRU2000 in der Vollversion, d.h. mit Netzunterstützung) fordert eine Liste der Dateien im zu sichernden Verzeichnis an. Leider liefert der NT Server das Ergebnis nicht schnell genug somit bekommt die Software einen Timeout und bricht in Folge nach einem Achtel der zu sichernden Dateien das Backup in diesem Verzeichnis ab. ARGHL.
Aber warum denn einfach, wenn es auch umständlich geht. Das Problem hat sich unter Verwendung des smbclients bzw. des wrapperscripts smbtar aus dem SAMBA Paket elegant umgehen lassen.
Der smbclient macht es unnötig, die Verzeichnisse zu mounten. Der Zugriff erfolgt direkt unter der Angabe des Servers und des zu sichernden Verzeichnisses. Zusätzlich verfügt er noch über einige Funktionen von tar. Damit läßt sich der Datenstrom direkt auf den Tapechanger leiten.
Das ganze Backup wird per cron Job angestoßen. Mittels mtx und der Abfrage des Wochentages wird das richtige Tape zur Schreibmechanik befördert. Dann werden die einzelnen zu sichernden Verzeichnisse mittels smbclient auf Band geschrieben und das Band wieder via mtx in die Kassette zurückbefördert. Die Rücksicherung erfolgt ähnlich.
Allerdings muß mittels mt noch die richtige Bandstelle angefahren werden. Sicher wird man nicht alle Server auf einen Schlag restaurieren müssen. Ein einfach zu bedienendes Benutzerinterface via Webbrowser rundet das Ganze dann ab.
Damit ist man auch nicht mehr an eine spezielle Plattform gebunden, sondern kann von jedem OS, für das es einen Browser gibt, auf die Sicherungsmechanismen zugreifen.
Im schlimmsten Fall lassen sich die Daten auch via telnet-login "von Hand" auf die NT Server zurückspielen.

Ende gut - alles sicher

Selbstverständlich sind auch und gerade unter Linux all die netten Features verfügbar, die wir von herkömmlichen Backup-Programmen bereits kennen und mehr oder weniger benutzen. Erwähnt sei hier am Rande Datenkompression, Statusberichte via eMail, Bandverwaltung, "Hilferufe" des Systems über Pager, Fax oder SMS und und und...
Im vorliegenden Fall war lediglich ein Statusbericht via eMail gewünscht. Diesem Wunsch sind wir natürlich gerne nachgekommen.
Allerdings sind wir dabei etwas über das Ziel hinausgeschossen - nach dem automatischen Ausdruck der 3.5 MB großen Auflistung aller gesicherter Dateien (ca.70 A4-Seiten) bat man uns doch bitte lediglich den erfolgreichen Abschluß und eventuell aufgetretene Fehler weiterzugeben :-).

Die Autoren
Andreas Lindenblatt ist Gründer der Firma Solution - The Computer People und installiert und administriert seit NetWare2.11 Netzwerke in allen Formen und Farben.
Chris Weber ist technischer Leiter der Solution und setzte 1994 - natürlich mit Linux - den ersten kommerziellen WebServer in Mannheim auf. Seitdem forciert er den Einsatz von Linux zur Lösung aller möglichen und unmöglichen Probleme.
Daniela Lindenblatt ist verantwortlich für die Bereiche Management und Marketing und hat in Linux eine neue Herausforderung gefunden.
Zu erreichen sind die drei unter azrael@solution.de, chris@solution.de und tila@solution.de