Elementare Backupwerkzeuge

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.


Inhalt

  1. Motivation
  2. Bandlaufwerke
    1. Typen
    2. Devices
    3. mt
    4. Blockgröße
  3. Archivierungsprogramme
    1. tar
      1. Die wichtigsten Befehle
      2. Einige Optionen
      3. Beispiele
      4. Beachtenswertes
    2. cpio
      1. Befehle
      2. Einige weitere Optionen
      3. Beispiele
      4. Beachtenswertes
    3. pax
      1. Befehle
      2. Einige weitere Optionen
      3. Beispiele
      4. Beachtenswertes
  4. Puffern
  5. dump/restore
    1. dump
      1. Befehlssyntax
    2. restore
      1. Befehle
      2. Einige Optionen
      3. Beispiele
      4. Beachtenswertes
  6. Sicherung im Netz
    1. rsh, ssh
    2. Direkter Zugriff
  7. Abschluss und Ausblick
    1. Welches Werkzeug?
    2. Amanda

Motivation

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.

Bandlaufwerke

Typen

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.

Devices

Auf einem Unix-System sind 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 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/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.

mt

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:

fsf, bsf
Vor- bzw. Zurückspulen zur nächsten Dateimarke.
offline
Zurückspulen zum Bandanfang und Auswerfen des Bands, sofern die Technik des Laufwerks dies erlaubt.
rewind
Zurückspulen zum Bandanfang.
status
Ausgabe des aktuellen Laufwerkszustands, Bandart, Bandposition, usw.

Blockgröße

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.

Variable Blockgröße

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.

Feste Blockgröße

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

Archivierungsprogramme

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.

tar

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.

Die wichtigsten Befehle

c
Legt ein Archiv an (create).
x
Kopiert Dateien aus einem Archiv (extract).
t
Listet den Inhalt eines Archivs auf (table).

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.

Einige Optionen

b Zahl
Blockgröße in 512-Byte-Blöcken (block size). Der Defaultwert ist 20.
f Dateiname
Archivdatei (file). - steht dabei für die Standardeingabe/-ausgabe.
p
Bewahre ursprüngliche Besitzer, Zugriffsrechte, und -zeiten (preserve).
v
Ausführlich (verbose).

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.

Beispiele

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 -)

Beachtenswertes

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.

cpio

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.

Befehle

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.

-i
Einlesen von Dateien aus dem Archiv (in). Das Archiv wird dabei von der Standardeingabe gelesen. Sollen nur bestimmte Dateien extrahiert werden, so können diese auf der Kommandozeile angegeben werden.
-o
Kopieren von Dateien in das Archiv (out). Das Archiv wird dabei auf die Standardausgabe geschrieben, die Liste der zu archivierenden Dateien von der Standardeingabe gelesen. Verzeichnisse werden nicht selbständig rekursiv eingepackt.
-p
Direktes Kopieren von Dateien (pass). Die Liste der zu kopierenden Dateien wird auch hier von der Standardeingabe gelesen.

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!

Einige weitere Optionen

-d
Automatisches Anlegen von benötigten Verzeichnissen (directories).
-H Format
Archivformats. Die verfügbaren Formate und ihre Bezeichnungen sind implementierungsabhängig.
-m
Das Änderungsdatum von Dateien beim Extrahieren erhalten (modification time).
-t
Zusammen mit -i Auflisten des Archivinhalts, ohne dass tatsächlich Dateien angelegt werden (table).
-u
Überschreiben vorhandener Dateien beim Extrahieren (unconditionally).
-v
Ausführlich (verbose).

Beispiele

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

Beachtenswertes

pax

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.

Befehle

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:

(nichts)
Auflisten des Archivinhalts.
-r
Extrahieren von Dateien aus einem Archiv.
-w
Kopieren von Dateien in ein Archiv.
-r -w
Direktes Kopieren von Dateien in ein Zielverzeichnis.

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.

Einige weitere Optionen

-f Dateiname
Angabe einer Archivdatei statt der sonst verwendeten Standardeingabe bzw. -ausgabe (file).
-pe
Vollständiges Wiederherstellen alle Besitzer, Zugriffszeiten und -rechte beim Auspacken (preserve everything).
-s Regulärer Ausdruck
Umschreiben der verarbeiteten Dateinamen nach einem regulären Ausdruck in ed(1)-Syntax (substitute).
-v
Ausführlich (verbose).
-x Format
Angabe des Archivformats. Die verfügbaren Formate und ihre Bezeichnungen sind implementierungsabhängig. Default ist das von POSIX standardisierte erweiterte tar-Format.
-X
Beschränkt die Rekursion auf ein Dateisystem.

Beispiele

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

Beachtenswertes

Puffern

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:

-i Dateiname
Eingabedatei (input). Ohne diese Angabe wird von der Standardeingabe gelesen.
-o Dateiname
Ausgabedatei (output). Ohne diese Angabe wird auf die Standardausgabe geschrieben.
-s Zahl
Blockgröße in Bytes (size).

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.

dump/restore

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.

dump

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.

Befehlssyntax

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..9
Gibt die Stufe der Sicherung an. 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.
a
Automatische Ermittlung der Bandkapazität (auto-size).
f Dateiname
Archivdatei (file). - 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.

restore

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.

Befehle

restore folgt erwartungsgemäß in seiner Befehlssyntax dem Kollegen dump, trennt allerdings wieder grundlegende Befehle und diese modifizierende Optionen. Die Hauptarbeitsmodi sind:

i
Interaktives Rückspielen (interactive).
r
Wiederherstellen eines Dateisystems (rebuild).
t
Auflisten des Inhalts (table).
x
Extrahieren einzelner, als zusätzliche Argumente aufgeführter Dateien (extract). Verzeichnisse werden dabei rekursiv ausgepackt.

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.

Einige Optionen

f Dateiname
Archivdatei (file). - steht für die Standardeingabe. Fehlt diese Angabe, dann wird auf die Environmentvariable TAPE und letztlich auf einen eincompilierten Default zurückgegriffen.
s Zahl
Vom wievielten Archiv auf einem Band gelesen werden soll. Gezählt wird ab 1.

Beispiele

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 -)

Beachtenswertes

Sicherung im Netz

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.

rsh, ssh

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.

Direkter Zugriff

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

Abschluss und Ausblick

Welches Werkzeug?

... 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.

Amanda

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.


Christian »naddy« Weisgerber <naddy@mips.inka.de>
$Id: backup.html,v 1.7 2006/01/26 16:31:34 naddy Exp $