Christian Weisgerber
27. Juni 1999
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.
Warum wollen wir eigentlich ein Backup von Daten oder einer Rechnerinstallation machen?
Man sagt den Deutschen nach, die 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 halbswegs 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 Medium 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 Bandlaufwerken entsprechende
(Character-)Devices zugeordnet. Die Namensgebung und Details variieren
zwischen den verschiedenen Unices, populär sind
/dev/rmt
N (von Magnetic
Tape), /dev/rst
N (von
SCSI Tape),
/dev/st
N unter Linux. FreeBSD mit CAM verwendet
/dev/rsa
N, 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 ggfs. 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/nrmt
N 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 Vielfaches 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.
-
steht dabei für die
Standardeingabe/-ausgabe.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 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 dafür 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!
-i
Auflisten des Archivinhalts, ohne
dass tatsächlich Dateien angelegt werden (table).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 alles 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(muster). 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.
ed
(1)-Syntax (substitute).tar
-Format.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, 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
geschätzig, gibt während der Sicherung Auskunft 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.
0
ist eine
Vollsicherung, 1
..9
sind inkrementelle
Sicherungen, die alle seit der letzten Sicherung geringerer Stufe
veränderten oder neu angelegten Dateien ins Archiv kopieren, womit
sich ausgetüftelte Backupstrategien realisieren lassen.-
steht für die Standardausgabe.
Fehlt diese Angabe, dann wird auf die Environmentvariable
TAPE
und letztlich auf einen eincompilierten Default
zurückgegriffen.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 restore
s
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.
-
steht für die Standardeingabe.
Fehlt diese Angabe, dann wird auf die Environmentvariable
TAPE
und letztlich auf einen eincompilierten Default
zurückgegriffen.Zurücklesen der Sicherung des /usr
-Dateisystems, nachdem
dieses mit mkfs
(8)/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 tapehost buffer -o /dev/nst0
bzw. das Zurücklesen von dort
# rsh tapehost 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.