Datensicherung gehört zu den grundlegenden Aufgaben der
Systembetreuung. Es soll ein Überblick gegeben werden, wie Bandlaufwerke
unter Unix angesprochen werden. Die grundlegenden Backupwerkzeuge werden
mit ihrer Arbeitslogik, Aufrufsyntax und ihren jeweiligen Besonderheiten
vorgestellt und zusätzlich ihre Kombination mit Pufferprogrammen und der
Betrieb im Netz erläutert.
Inhalt
Motivation Bandlaufwerke Typen Devices mt Blockgröße Archivierungsprogramme tar Die wichtigsten Befehle Einige Optionen Beispiele Beachtenswertes cpio Befehle Einige weitere Optionen Beispiele Beachtenswertes pax Befehle Einige weitere Optionen Beispiele Beachtenswertes Puffern dump/restore dump Befehlssyntax restore Befehle Einige Optionen Beispiele Beachtenswertes Sicherung im Netz rsh, ssh Direkter Zugriff Abschluss und Ausblick Welches Werkzeug? Amanda
Warum wollen wir eigentlich ein Backup von Daten oder einer Rechnerinstallation machen?
Man sagt den Deutschen nach, sie seien versicherungswütig. Bei der Datensicherung trifft man aber regelmäßig die Mentalität »es wird schon nichts passieren« oder »was ich heute könnt besorgen, das verschieb ich lieber doch auf morgen«. Jeder, der längere Zeit auch nur halbwegs ernsthaft Rechnersysteme betrieben hat, weiß von versagenden Festplatten, versehentlich gelöschten Daten, gescheiterten Updates, u.ä. zu berichten. Geradezu symbolhaft ist dem Autor wenige Tage vor Verfassen dieses Artikels eine Festplatte im wahrsten Sinne des Wortes abgeraucht. Dank der vorhandenen Datensicherung ein zwar immer noch ärgerlicher, aber rasch reparabler Vorfall.
Kurzum, Backup muss sein. Darum sollen hier die elementaren Unix-Werkzeuge für diesen Zweck vorgestellt werden. Das Ganze ist ausdrücklich nicht Linux-spezifisch.
Das übliche Mittel zur Datensicherung sind nach wie vor Magnetbänder, die hohe Kapazitäten mit vergleichsweise billigen Medien vereinen. Es gibt eine ganze Reihe verschiedener Systeme, die in Geschwindigkeit, Kapazität, Zuverlässigkeit und Preis ein breites Spektrum abdecken. Gängige Band- und Laufwerksformate sind:
Eine Beschreibung der einzelnen Systeme würde den Rahmen dieses Artikels sprengen. Bandlaufwerke, im deutschen Jargon auch »Streamer« abkürzend für »streaming tape drive« genannt, werden heute nahezu universell über SCSI angeschlossen.
Auf einem Unix-System sind den Bandlaufwerken entsprechende (Character-)Devices zugeordnet. Die Namensgebung und Details variieren zwischen den verschiedenen Unices, populär sind /dev/rmtN (von Magnetic Tape), /dev/rstN (von SCSI Tape), /dev/stN unter Linux. FreeBSD mit CAM verwendet /dev/rsaN, von Sequential Access (Device). Das oft anzutreffende führende »r« steht für Raw-Device als Gegensatz zu dem, bei Bandlaufwerken heutzutage üblicherweise nicht mehr vorhandenen, mountbaren Block-Device.
Bisweilen ist im Namen des Devices auch die Dichte, mit der das Band geschrieben wird, oder eine eventuelle Hardware-Komprimierung durch das Laufwerk kodiert. Bei Linux und BSD stellt man das gegebenenfalls mit mt(1), s.u., ein.
Tape-Devices lassen sich wie normale Dateien ansprechen und setzen diese Semantik auf Band um. Man öffnet die Datei [open(2)], liest [read(2)] oder schreibt [write(2)] sequentiell die Daten, schließt [close(2)] die Datei (Dateimarke wird gesetzt). Ein wahlfreiere Zugriff [lseek(2)] ist i.A. nicht möglich. Alle Tape-Devices kommen in zweifacher Ausführung: rewinding und non-rewinding. Das Non-rewinding-Device hat noch ein führendes »n« im Namen (/dev/nrmtN usw.). Bei einem Rewinding-Device wird, wenn das Device geschlossen wird, das Band zum Anfang zurückgespult. Beim Non-rewinding-Device geschieht das nicht, es können dort also mehrere Dateien hintereinander auf ein Band geschrieben werden.
Das Programm mt(1) erlaubt eine Ansteuerung von Bandlaufwerken, die über die Möglichkeiten der Datei-API hinausgeht. Technisch funktioniert das in Form von ioctl(2)-Aufrufen, die der Treiber entsprechend umsetzen muss. Die Möglichkeiten von mt variieren je nach Betriebssystem und Bandlaufwerk, Details finden sich in der lokalen Man-Page. Grundlegende Aufrufsyntax:
mt [-f Device] Befehl
Wird kein Device angegeben, so verwendet mt das in der Environment-Variable TAPE angegebene und als Letztes einen eincompilierten Default. Zum üblichen Grundumfang der möglichen Befehle gehören:
Ein etwas unübersichtlicher Aspekt, über den man gelegentlich stolpert, und zu dem viel Verwirrung herrscht, ist das Thema Blockgröße. Die folgende Darstellung ist weitgehend der sa(4)-Man-Page von FreeBSD entnommen.
Grundsätzlich gibt es zwei Modi, variable und feste Blockgröße. Welche der beiden Varianten verwendet wird, hängt vom Laufwerkstyp und manchmal auch vom Treiber und der Konfiguration ab.
Mit jedem Schreibzugriff wird ein einziger logischer Datensatz auf das Band geschrieben. Man kann nie nur einen Teil eines Datensatzes von Band lesen oder schreiben, allerdings kann man einen größeren Block anfordern und einen kleineren Satz einlesen. Auch mehrere Blöcke können nicht in einem Zugriff gelesen werden. Die Daten eines einzelnen Schreibzugriffs werden also auch mit einem einzelnen Lesezugriff ausgelesen. Jede vom Gerät(etreiber) unterstützte Blockgröße kann verwendet werden, typischerweise zwischen einem Byte und 64kB.
In dieser Betriebsart wird eine vom Benutzer geschriebende Datenmenge als eine Folge von Blöcken fester Größe zum Band gereicht. Die Daten mögen einen zusammenhängender Speicherbereich bilden, aber sie werden als eine Reihe unabhängiger Blöcke behandelt. Man kann nie eine Datenmenge schreiben, die nicht einem exakten Vielfachen der Blockgröße entspricht. Dieselben Daten können als verschiedene Mengen von Datensätzen gelesen bzw. geschrieben werden. In anderen Worten, Blöcke die zusammen geschrieben wurden, können getrennt gelesen werden, und umgekehrt.
Alle weiter unten beschriebenen Archivierungsprogramme erlauben die Angabe der Blockgröße, auch wenn wegen der Beschränkung auf Wesentliches die entsprechende Option nicht bei allen vorgestellt wird. Im Allgemeinen gibt es keinen Grund, von der Defaultblockgröße abzuweichen, es sei denn, man möchte Daten mit einem System austauschen, das eine andere Blockgröße verwendet, und sich sonst eine Formatinkompatibilität ergeben würde. Möchte man eine Datei direkt auf Band schreiben, oder davon lesen, und die Blockgröße bestimmen, dann kann man dafür dd(1) verwenden. dd erlaubt auch ein sogenanntes »Reblocking«, d.h. Lesen mit einer bestimmten Blockgröße und Schreiben mit einer anderen, z.B.:
$ dd if=quelle ibs=512 of=ziel obs=1024
Im Folgenden werden einige populäre Archivierungsprogramme näher dargestellt. Keineswegs sollen diese Werkzeuge erschöpfend beschrieben werden. Ihre Implementierungen auf verschiedenen Unices variieren in vielen Details, und insbesondere die GNU-Inkarnationen weisen eine schier unüberschaubare Optionsfülle auf. Hier soll nur die grundsätzliche Funktionsweise vorgestellt werden, für eine Beschreibung aller Details der konkret vorliegenden Implementierung sei auf die dazugehörigen Man-Pages verwiesen.
Es ist wichtig zu verstehen, dass diese Programme die zu sichernden Dateien nicht einzeln schreiben, sondern zu einem Archiv zusammenfassen, das auf Band nur eine einzelne Datei bildet. Dieses Archiv muss auch keineswegs auf ein Band geschrieben werden, es kann auch als normale Datei in einem Filesystem gespeichert werden.
Sehr beliebt ist tar(1) (tape archiver), der Unix in unzähligen Varianten schon mindestens seit V7 begleitet. tar packt als Argumente übergebene Dateien in ein Archiv ein oder daraus aus. Aufgrund seiner langen Geschichte hat tar noch eine von den heutigen Konventionen etwas abweichende Aufrufsyntax:
$ tar BefehlOptionen [Parameter] Datei ...
Der Befehl besteht aus einem Buchstaben, unmittelbar gefolgt von ebenfalls einbuchstabigen Optionen. Falls Optionen Parameter nehmen, dann werden diese erst in nachfolgenden Wörtern übergeben, und zwar in derselben Reihenfolge, wie die Optionen auftauchen. Alles nach den durch die angegebenen Optionen bestimmte Zahl von Parameter wird als Dateinamen behandelt.
Neuere Implementierungen unterstützen oft mehr oder minder eine moderne Syntax mit -Option. Die Details variieren aber, wohingegen die klassische Syntax universell verstanden wird.
tar kennt auch Befehle zum Anhängen oder Ergänzen eines Archivs, diese sind jedoch im Allgemeinen nicht mit Bandlaufwerken verwendbar, weshalb an dieser Stelle nicht weiter auf sie eingegangen werden soll.
Tatsächlich ist die gängigste Anwendung von tar heute gar nicht mehr das Sichern von Daten auf Band, sondern er wird als allgemeines Archivierungswerkzeug zum Bündeln von Dateibäumen zu einer einzelnen Archivdatei eingesetzt. Viele Unix-Neulinge kennen ihn nur in dieser Funktion und sind dann gehörig verdutzt, wenn sie tar aus Versehen ohne Option f aufrufen, woraufhin er auf die in der Environmentvariable TAPE angegebene Datei oder letztlich auf einen eincompilierten Default zurückgreift, der je nach System alles Mögliche sein kann (/dev/rmt8, Standardausgabe, usw.).
tar packt selbständig rekursiv Dateibäume ein, so dass man ihm typischerweise einen oder mehrere Verzeichnisnamen übergibt. Manche Implementierungen kann man mittels Option (l bei GNU tar) darauf beschränken, bei der Rekursion nicht auf andere Dateisysteme zu wechseln, was insbesondere für ein Systembackup, wo man nicht alle Partitionen sichern will, sinnvoll ist.
Anlegen einer Archivdatei, die ein Verzeichnis beinhaltet, mit Ausgabe der Namen aller eingepackten Dateien:
$ tar cvf archiv.tar verzeichnis
Ausführliches Anzeigen des Inhalts eines auf Band befindlichen Archivs mit der vom Default abweichenden Blockgröße von 16kB:
$ tar tfvb /dev/nst0 32
Man beachte hier beispielhaft die Aufrufsyntax. Option f nimmt den Devicenamen /dev/nst0 als Parameter, v steht für sich allein, und die Blockgröße gehört zu Option b.
Rücklesen eines Backups von Band:
# export TAPE=/dev/nst0
# cd /
# tar xp
Einer der Dauerbrenner unter den Fragen neuer Unix-Benutzer ist, wie man ein Verzeichnis (ein Dateisystem) komplett und vollständig kopieren kann. Neben aufgebohrten modernen Implementierungen von cp(1), deren (Un)fähigkeiten und notwendige Optionen in dieser Beziehung schwanken und schon für manche unangenehme Überraschung gesorgt haben, können auch alle hier besprochenen Backupwerkzeuge für diesen Zweck eingesetzt werden. Für tar lautet die Befehlszeile:
# cd quelle; tar cf - . | (cd ziel; tar xpf -)
tar ist nicht gleich tar. Die diversen Implementierungen auf verschiedenen Unices weichen teilweise ganz erheblich in Funktionalität und Optionsnamen voneinander ab. Insbesondere ist nicht jedes tar ein GNU tar. Unbedingt die lokale Anleitung zu Rate ziehen!
Auch die Archivformate können abweichen. Trotz allseitiger, im Allgemeinen schlecht dokumentierter Bemühungen die Austauschbarkeit zu gewährleisten, kann es im Extremfall zu Inkompatibilitäten zwischen verschiedenen Systemen kommen.
GNU tar kann nur 16-Bit Devicenummern im Archiv speichern, so dass es für ein Backup von /dev unter SVR4 oder BSD nicht geeignet ist.
tar nimmt von alleine alle Informationen über eine Datei ins Archiv auf. Nur beim Rücklesen eines Backups ist die Option p notwendig, um alle Rechte originalgetreu zu restaurieren.
Man packt niemals Dateien mit absolutem Pfad ein. tar extrahiert Dateien üblicherweise an den im Archiv gespeicherten Pfad. Bei relativen Pfaden kann man etwas auslesen, wohin es gerade praktisch ist. Bei absoluten Pfaden hat man keine Wahl. Im Fall von /etc u.ä. kann das fatal sein. GNU tar behandelt per Default beim Auspacken absolute Pfade als relativ, aber bei manchen anderen Implementierungen (z.B. Solaris) ist man auf den Pfad im Archiv festgelegt.
Eine bemerkenswerte eigenständige Implementierung mit Schwerpunkt auf Geschwindigkeit und POSIX-Konformität (und einer eigenwilligen Befehlssyntax) ist Jörg Schillings star, auf den ich hiermit kurz hinweisen möchte, auch wenn er bei keinem Betriebssystem von Haus aus mitgeliefert wird.
Während tar(1) eher in der BSD-Ecke heimisch ist, scheint sich cpio(1) (copy in/out) mehr bei System V Bekannt- und Beliebtheit zu erfreuen. Kein Wunder, wurde die ursprüngliche Implementierung doch im Zweig des kommerziellen AT&T UNIX mit System III entwickelt. cpio hat prinzipiell eine ganz ähnliche Funktionalität wie tar, nur eine völlig andere Aufrufsyntax.
cpio folgt der heute allgemein üblichen Optionssyntax. Grundsätzlich muss aber auch hier eine von drei Betriebsarten ausgewählt werden, deren Verhalten durch weitere Optionen modifiziert wird.
Beim Einlesen von Dateien aus einem Archiv werden eventuell angegebene Namen als Muster nach den Shell-Globbing-Regeln verstanden, mit dem Unterschied, dass »/« und ein führender ».« auch von Jokerzeichen getroffen werden. Nicht vergessen, solche Muster mit Anführungszeichen vor einer Expansion durch die Shell selbst zu schützen!
Sichern der Benutzerverzeichnisse auf Band:
# cd /
# find home -print | cpio -o >/dev/nst0
Wiedereinspielen des Verzeichnisses des Benutzers naddy von obigem Backup:
# cd /
# cpio -iumd 'home/naddy*' </dev/nst0
Mit rpm2cpio(1) kann man eine .rpm-Datei in ein cpio-Archiv umwandeln. Und so kann man sich ausführlich anzeigen lassen, was sich darin befindet:
$ rpm2cpio irgendwas.rpm | cpio -itv
Und natürlich kopieren eines Verzeichnisses:
# cd quelle; find . -print | cpio -pumd ziel
Auch hier gilt, nicht jedes cpio ist ein GNU cpio.
cpio stellt je nach Implementierung eine ganze Reihe von Archivformaten zur Verfügung, darunter auch welche von tar, wobei der Default oft heute unakzeptable Beschränkungen auf 16-Bit Inode- und Devicenummern aufweist. Das ist gerade auch bei GNU cpio so. Wer damit ein Linux- oder BSD-Dateisystem sichern möchte, für den ist die explizite Angabe eines SVR4-Archivformats mit -H newc oder -H crc praktisch Pflicht.
Wenn man cpio-Archive zwischen verschiedenen Rechnern portieren will, sollte man auch beachten, dass das verwendete Format auf beiden Seiten verstanden wird.
cpio hat mit -d, -m, -u, u.a. eine ganze Reihe von Optionen, die das Restaurieren von Eigentümern, Rechten, und Anlegen von Verzeichnen beim Extrahieren von Archiven betreffen. Der Default ohne diese Angaben ist nicht zum Rückspielen von Backups geeignet.
Die Erstellung einer Liste zu archivierender Dateinamen mit find wirft ein Problem auf. Die Ausgabe von find führt jede Datei auf einer Zeile auf. Nun ist der Zeilentrenner '\n' aber wie alle außer '/' und '\0' durchaus ein gültiges Zeichen in Unix-Dateinamen. Die GNU-Inkarnationen von find und cpio erlauben deshalb mit -print0 bzw. -0 die Verwendung von '\0' als Namenstrenner.
Auch hier gilt wieder: keine absoluten Pfade verwenden!
Dritter im Bunde neben tar(1) und cpio(1) ist das relativ unbekannte pax(1). Der Name wird gerne von »portable archive interchange« abgeleitet, aber die lateinische Bedeutung von »Frieden« ist sicher nicht ganz zufällig. pax entstand, als sich das IEEE-POSIX-Gremium nicht auf eine Standardisierung von tar oder cpio einigen konnte, und man kurzerhand ein neues Programm aus der Taufe hob. So wundert es nicht, dass pax dasselbe in grün macht wie seine beiden Vettern. Bei vergleichbarer Funktionalität zu tar und cpio bringt es die dritte völlig andere Benutzerschnittstelle mit. Nicht umsonst sind auf OpenBSD alle drei Programme Links auf dieselbe ausführbare Datei, die sich nur, je nachdem wie sie aufgerufen wurde, mit entsprechend anderer Benutzerschnittstelle gibt.
Wie cpio hat pax eine normale Aufrufsyntax mit durch Befehlsoptionen festgelegten Grundmodi, zusätzlichen Optionen, die deren genaue Arbeitsweise modifizieren, und gegebenfalls als weitere Argumente aufgeführten Dateinamen(mustern). Es gibt vier Betriebsarten, die durch die Kombination der Befehlsoptionen -r (read) und -w (write) festgelegt werden:
Beim Auflisten und Extrahieren wird das Archiv von der Standardeingabe gelesen, beim Anlegen eines Archivs dieses auf die Standardausgabe geschrieben. Werden beim Kopieren von Dateien in ein Archiv oder Zielverzeichnis kein Dateinamen als Argumente übergeben, dann werden sie von der Standardeingabe gelesen. Wie bei tar wird bei Angabe eines Verzeichnisses ein Dateibaum selbständig rekursiv verarbeitet.
Sichern des /-Dateisystems auf Band:
# pax -w -f /dev/nst0 -X /
Sichern aller Dateien neuer als stempel mit Umschreiben von absoluten Pfaden in relative:
# find / -newer stempel | pax -w -s',^/,,' >/dev/nst0
Ausführliches Auflisten aller in einem Unterverzeichnis src befindlichen Dateien in einem Archiv:
$ gzip -cd paket.tar.gz | pax -v 'src/*'
Und auch hier wieder das Kopieren eines Verzeichnisses:
# pax -rw -pe quelle ziel
Es gibt noch kein GNU pax, aber die im Linux- und BSD-Bereich übliche, von 4.4BSD stammende Implementierung weist ebenfalls eine Reihe von Erweiterungen gegenüber den POSIX-Vorgaben auf, deren Vorhandensein man auf anderen Systemen nicht voraussetzen kann.
Für die Archivformate gelten analoge Hinweise wie bei cpio.
Gegenüber tar und cpio besonders mächtig ist die Möglichkeit, beim Anlegen eines Archivs oder beim Extrahieren die Dateinamen mittels eines regulären Ausdrucks umzuschreiben.
Wenn ein Bandlaufwerk schreibt/liest, dann transportiert es das Band mit einer bestimmten, je nach Aufzeichnungsart festen oder in gewissen Grenzen variablen Geschwindigkeit. Daraus resultiert eine bestimmte Übertragungsgeschwindigkeit und die Daten müssen entsprechend schnell geliefert/abgenommen werden, damit das Bandlaufwerk unterbrechungsfrei durchläuft, damit es »streamt«. Die Laufwerke verfügen natürlich über einen internen Puffer, aber dieser ist vergleichsweise klein. Reißt der Datenstrom lang genug ab, dann muss das Laufwerk anhalten, und, wenn es weitergehen soll, ein Stück zurückspulen und neu ansetzen.
So ähnlich sich tar, cpio, und pax trotz der oberflächlichen Unterschiede sind, so teilen sie sich auch ein Problem. Sie laufen alle als ein einzelner Prozess, der abwechselnd die Daten aus dem Dateisystem liest und ein Stück Archivdatei schreibt bzw. vom Archiv liest und ins Dateisystem schreibt, wobei der Prozess beim Lesen und Schreiben jeweils blockiert, bis die angeforderten Daten geliefert sind. Ein weiteres Problem sind hohe Laufzeitverzögerungen beim (in einem späteren Abschnitt beschriebenen) Betrieb über ein Netzwerk. All dies führt oft dazu, dass das Archivierungsprogramm das Bandlaufwerk nicht streamen lässt. Das ist laut, verschleißintensiv für Band und Laufwerk, und der Gesamtdurchsatz bricht ein.
Abhilfe schafft hier eine externe Pufferung. Gängige Programme dafür sind buffer(1) und team(1), die leider normalerweise nicht zur Grundinstallation eines Betriebssystems gehören, aber leicht nachinstalliert werden können. buffer benutzt ein bis zu 1MB großes Segment System-V-Shared-Memory, team kommt mit Pipes aus. buffer und team zerlegen sich in lesende und schreibende Prozesse, die nur an einem Ende blockieren, und glätten damit den Datenstrom, so dass ein Bandlaufwerk gleichmäßig durchlaufen kann, solange das Archivierungsprogramm die Daten nur im Zeitmittel schnell genug liefert.
Die wichtigsten Optionen für buffer sind:
Beispiel:
# tar cf - /usr | buffer -o /dev/nst0
Ein Nachteil der Pufferung mit zusätzlichen Hilfsprogrammen ist, dass das Verteilen eines einzelnen Archivs über mehrere Bänder (volumes) hinweg, wie es von manchen Implementierungen der oben beschriebenen Archivierungsprogramme unterstützt wird, nicht mehr möglich ist, weil über die Pipe die Erkennung des Medienendes durch weiche Schreibfehler nicht zurückübertragen werden kann. (team bietet allerdings die Erkennung des Medienendes und Gelegenheit zum Wechseln selbst an.) Auch ein Auswerten der Rückgabewerte der Programme in Shellskripten ist schwierig. Der oben kurz erwähnte star verfügt übrigens über einen eigenen Puffermechanismus.
Falls durch widrige Umstände auch der durchschnittliche Durchsatz vom/zum Dateisystem zu langsam ist, um mit dem Bandlaufwerk mitzuhalten, ist guter Rat teuer. Möchte man hier ein wirklich streamendes Laufwerk, hilft nur das ganze Archiv erst auf einer Festplatte zwischenzulagern, was entsprechenden Platz voraussetzt.
Das Backupwerkzeug überhaupt, insbesondere in der BSD-Welt, ist die Kombination dump(8) und restore(8), auf manchen Systemen auch mit dem Dateisystemnamen als Präfix versehen, z.B. Solaris ufsdump. Die Namen sind selbsterklärend, es wird ein Abzug des Dateisystems gemacht bzw. wieder hergestellt. Die BSD-Man-Page verweist die Geschichte der Programme bis auf UNIX V6 zurück. Eine Linux-Version gab es in den ersten Jahren dieses Betriebssystems nicht, aber mittlerweile ist eine Portierung des dump/restore von 4.4BSD für das ext2-Dateisystem auch schon seit längerer Zeit verfügbar. Erstaunlicherweise ist dump bei Linux-Benutzern bis heute kaum bekannt.
Für Backups ist dump, um eine amerikanische Redewendung zu bemühen, das Beste seit geschnittenem Brot. Es ist kein Werkzeug für den normalen Benutzer, sondern richtet sich an den Systemverwalter. Es sichert ganze Dateisysteme, kann inkrementelle Sicherungen, kann Archive auf mehrere Bänder verteilen und puffert selbständig. Wird dump von einem TTY aus gestartet, so ist es recht geschwätzig, gibt während der Sicherung in Abständen Auskunft über den bisher geschriebenen Anteil und die geschätzte noch verbleibende Zeit, und schreit notfalls um Hilfe.
Anders als die pax-Familie greift dump nicht über die normale Dateisystem-API mit open(2), read(2), write(2), stat(2), usw. zu, sondern liest direkt aus dem Dateisystem über das zugeordnete (Raw-)Device. Dadurch ist es extrem robust gegen allerlei pathologische Zustände, welche die anderen Archivierer ins Straucheln bringen können, und kann dünn besetzte Dateien (sparse files) genau erfassen. Ein zugegebenermaßen schon älterer Vergleichstest, aus dem dump/restore klar als Sieger hervorgehen, ist Torture-Testing Backup and Archive Programs (1991) von Elizabeth D. Zwicky.
Die Aufrufsyntax von dump folgt denselben altertümlichen Konventionen wie tar:
# dump Optionen [Parameter] Dateisystem
Optional kann auch eine moderne Syntax mit -Option und unmittelbar auf die Option folgendem Parameter verwendet werden.
Beispiel für eine einfache Vollsicherung eines Dateisystems:
# dump 0af /dev/nrsa0 /usr
oder
# dump 0f - /usr >/dev/nst0
dump versucht abzuschätzen, wieviele Bänder für eine Sicherung erforderlich sind, und fordert den Benutzer am vermuteten Ende zum Medienwechsel auf. Dazu hat es mehrere Optionen, die eine direkte oder indirekte Angabe der Bandkapazität ermöglichen. Diese sind allerdings für heutige Aufzeichnungsverfahren und insbesondere das Schreiben von mehreren Archiven hintereinander auf ein einzelnes Band wenig brauchbar, weshalb sie hier nicht beschrieben werden. Ersatzweise gibt es die Option a, mit der dump einen weichen Schreibfehler als Bandende interpretiert. Leider unterstützt die aktuelle Linux-Portierung im Gegensatz zu den BSD-Versionen diese Option nicht. Schreibt das Programm allerdings auf die Standardausgabe, dann verzichtet es auf die Kapazitätsschätzung. Da die Defaultschätzung von dump unbrauchbar klein ist, muss man sich entweder der einen oder der anderen Methode bedienen.
Zum Rücklesen der mit dump gesicherten Daten dient dessen Partnerprogramm restore. dump legt einen zentralen Index aller gespeicherten Dateien und Verzeichnisse am Anfang des Archivs ab, was restore eine rasche Auflistung des Inhalts erlaubt, ohne dass dazu das ganze Archiv durchlaufen werden muss. Außerdem ist dieser Index die Grundlage für restores interaktiven Modus.
restore folgt erwartungsgemäß in seiner Befehlssyntax dem Kollegen dump, trennt allerdings wieder grundlegende Befehle und diese modifizierende Optionen. Die Hauptarbeitsmodi sind:
Besondere Beachtung verdient der interaktive Modus. Es ist vergleichsweise lästig, aus einem umfangreichen Archiv einzelne Dateien zurückzulesen, besonders, wenn man auch deren genauen Namen nicht weiß und erst eine Auflistung des Inhalts durchsuchen muss. restore -i liest nur den zentralen Index des dump-Archivs ein und liefert dann einen Kommandozeilenprompt, wo man sich mit cd und ls durch die Verzeichnisse hangeln, mit add Dateien und Verzeichnisse markieren, und diese schließlich mit extract in einem Rutsch auspacken kann. Wer als Systemadministrator häufig Dateien seiner Benutzer wieder herstellen muss, weiß diesen interaktiven Modus zu schätzen.
Zurücklesen der Sicherung des /usr-Dateisystems, nachdem dieses mit mkfs(8) bzw. newfs(8) initialisiert wurde:
# export TAPE=/dev/nst0
# cd /usr
# restore rs 2
Wiederherstellen eines Benutzerverzeichnisses aus einer Sicherung des /home-Dateisystems:
# cd /home
# restore xf /dev/nst0 ./naddy
Und zu guter Letzt das vollständige Kopieren eines Dateisystems:
# dump 0f - quelle | (cd ziel; restore rf -)
Ein wichtiges Kriterium in heterogenen Umgebungen, wo man ein Backup vielleicht auch auf einem anderen Betriebssystem als dem des schreibenden Rechners zurücklesen möchte, ist die Portabilität der Archive. Leider waren dazu bezüglich dump keine zuverlässigen Angaben zu bekommen. Empirisch lässt sich feststellen, dass Linux/i386 und FreeBSD/i386 trotz der verschiedenen Dateissysteme (ext2, FFS) mit den Archiven des jeweils anderen keine Probleme zu haben scheinen. Auch eine andere Bytefolge scheint verarbeitet zu werden. Schwierigkeiten könnten Erweiterungen wie ACLs verursachen.
Da dump/restore einen Komplettindex des Dateisystems erstellen, benötigen sie entsprechend viel Speicher. Bei Systemen mit besonders kleinem Hauptspeicher muss eventuell genügend Swap vorhanden sein.
Wer zu Hause mehr als einen Rechner hat, oder an Hochschule, Arbeitsplatz, usw. eine kleine Arbeitsgruppe, der möchte natürlich nicht jedem Rechner ein eigenes Bandlaufwerk spendieren. Es bietet sich an, Backups über das Netz zu fahren, wo doch die schönen 10, 100, oder mehr Mbit/s nachts völlig brach liegen.
Es ist naheliegend, das Archivierungsprogramm auf die Standardausgabe (von der Standardeingabe) schreiben (lesen) zu lassen, und die Übertragung zum Bandrechner über rsh(1) oder ssh(1) abzuwickeln, wo dann ein dd auf das Band zugreift. Sinnvollerweise kann man dort aber auch gleich eine Pufferung mit buffer oder team verwenden.
Beispielhaft sei hier die Sicherung auf einen fernen Rechner
# tar cf - home | rsh host buffer -o /dev/nst0
bzw. das Zurücklesen von dort
# rsh host buffer -i /dev/nst0 | tar xpf -
dargestellt. Die Konfiguration von rsh oder ssh soll hier nicht behandelt werden. Es sei angemerkt, dass man den Rechenzeitbedarf von ssh auf langsamen Rechnern nicht unterschätzen sollte, der den resultierenden Durchsatz bis zur Unbrauchbarkeit verlangsamen kann.
GNU tar, star, GNU cpio und dump unterstützen auch direkt den Zugriff auf ein Bandlaufwerk auf einem anderen Rechner im Netz, indem man als Zieldatei einfach User@Host:Device oder bei gleichen Benutzern kurz Host:Device angibt. Das setzt für Backupzwecke allerdings weitgehende Zugriffsrechte auf dem Zielrechner über rsh voraus, die je nach Umgebung nicht akzeptabel ist. Bei tar und cpio fehlt dann auch wieder die Pufferung, für dump ist das allerdings ein bequemes Verfahren. Auf dem Zielrechner wird rmt(8) gestartet, dem mit einem einfachen Protokoll Lese-/Schreibbefehle übermittelt werden. Bisweilen werden die netzfähigen Versionen von dump/restore auch rdump/rrestore genannt. Einige Praxisbeispiele:
Sichern des /-Dateisystems auf einen fernen Rechner:
# tar clf host:/dev/nst0 /
Ausführliches Auflisten eines fernen Archivs:
# cpio -itvF host:/dev/nst0
Interaktives Rücklesen mit restore übers Netz:
# rrestore if host:/dev/nst0
... wählt man nun am besten für eine einfache Datensicherung? Diese Frage lässt sich leider allgemein nicht beantworten. Ein wichtiger Aspekt ist, dass das verwendete Programm auch dann verfügbar ist, wenn man es wirklich benötigt, d.h. es sollte auf der Wurzelpartition und auf den Minimalsystemen für Notfälle vorhanden sein. Wer z.B. star verwenden will, der alle anderen Implementierungen von tar (und cpio und pax) deklassiert, der muss selbst die Verfügbarkeit des Programms für den Fall der Fälle sicherstellen.
Generell bringt dump die besten Voraussetzungen mit, aber vielleicht möchte man nur bestimmte Dateien und keine ganzen Dateisysteme sichern. Oder die Praxis macht einem ganz einfach einen Strich durch die Rechnung. Was soll man von einem System halten, das ein lokales dump nach /dev/null mit 600kB/s bewältigt, über das lokale Netz zum Bandrechner mit rcp(1) ebenfalls 600kB/s erreicht, aber bei einem rdump dorthin auf lächerliche 50kB/s zusammenbricht? Das Bandlaufwerk hat einen Durchsatz von ungefähr 250kB/s, damit ist an ein Backup nicht zu denken, selbst wenn man die Geduld aufbringen wollte, eine Sicherung mit der Geschwindigkeit eines Diskettenlaufwerks (sic) durchzuführen. Mit
# tar clf - $fs | buffer | rsh $host buffer -o $tape
liefert der zu sichernde Rechner dagegen 320kB/s, was allemal reicht das Bandlaufwerk zu bedienen.
Es darf nicht übersehen werden, dass die hier vorgestellten Programme elementare Werkzeuge sind, die der Sicherung einzelner Rechner und ansonsten nur als Grundlage für komplexere Backuplösungen dienen sollen. Auf ein solches leistungsfähigeres Paket möchte ich noch abschließend kurz hinweisen.
Hat man einen kleinen Rechnerverbund und möchte regelmäßige, automatische Backups von allen Maschinen fahren, dann ist das ein Fall für den »Advanced Maryland Automatic Network Disk Archiver«, kurz Amanda. Das ist ein recht umfangreiches, leistungsfähiges, auf Anhieb nicht leicht durchschaubares Paket. Es gibt einen Bandrechner, an dem sich das Laufwerk befindet, und auf dem der Server installiert wird, während die zu sichernden Rechnern mit dem Client auszustatten sind.
Von cron(8) angestoßen fragt der Serverrechner der Reihe nach die Clientrechner ab und lässt sich von ihnen mittels dump (oder GNU tar) erstellte volle und inkrementelle Backups schicken. Kerberos wird unterstützt, so vorhanden. Eine zentrale Konfiguration für den Server gibt vor, welche Dateisysteme von welchen Rechnern und mit welcher Priorität zu sichern sind, wieviele Bänder insgesamt vorhanden und in einem Zyklus sind, usw. Dabei werden Indizes angelegt, so dass man mit amrecover(8) in der Art von restore -i bequem angeben kann, welche Dateien von welchem Datum man von welchem Rechner haben möchte, und Amanda sagt einem, welche Bänder einzulegen sind, und holt die Daten zurück.
Ein tolles Paket für mittlere Backup-Bedürfnisse.