From: Christian Weisgerber (naddy_at_mips.rhein-neckar.de)
Date: 11. Jan 1999
Da es mit Vorträgen auf dem Monatstreffen irgendwie nichts wird, hier
ein etwas längerer Beitrag zu einem Thema, bei dem ich heute ein
plötzliches Mitteilungsbedürfnis verspürt habe. Fragen, Diskussion,
Ergänzungen willkommen.
Ich gehe absichtlich nicht im Detail auf die Aufrufsyntax der einzelnen
Programme ein. Dafür gibt es die man(1,7)-Pages.
----------------
Man sagt den Deutschen nach, die seien versicherungswütig. Bei der
Datensicherung treffe ich aber regelmäßig eine 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 Fest-
platten, versehentlich gelöschten Daten, gescheiterten Updates, u.ä. zu
berichten.
Backup muss sein.
Bandlaufwerke
-------------
Das übliche Medium zur Datensicherung sind nach wie vor Magnetbänder,
die hohe Kapazitäten mit vergleichsweise billigen Medien vereinen. Heute
gängig sind:
- QIC mit "großen" Kassetten, QIC-1000 aufwärts.
- DAT
- Exabyte
- DLT
Bandlaufwerke, im deutschen Jargon auch "Streamer" abkürzend für
"streaming tape drive" genannt, werden heute universell über SCSI
angeschlossen.
Unter Unix sind Bandlaufwerken entsprechende (Character-)Devices
zugeordnet. Die Namensgebung und Details variieren zwischen den
verschiedenen Unices, populär sind /dev/rmt* (für Magnetic Tape),
/dev/rst<n> (für Scsi Tape), /dev/st<n> unter Linux. FreeBSD mit CAM
verwendet /dev/rsa<n>, für Sequential Access (Device). Das oft
anzutreffende führende 'r' steht für "raw device" als Gegensatz zu einem
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) ein.
Tape-Devices lassen sich wie normale Dateien ansprechen und setzen diese
Semantik auf Band um. Man öffnet die Datei (-> Dateianfangsmarke),
schreibt die Daten (-> Daten), schließt die Datei (-> Dateiendemarke).
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 usw.). Bei einem Rewinding-Device wird, wenn das Device
geschlossen wird, das Band zurückgespult, beim Non-rewinding-Device
geschieht das nicht, es können 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, zum üblich Grundumfang gehören vor- und zurückspulen zur
n-ten Datei auf dem Band und ein gänzliches Zurückspulen des Bands.
Im Folgenden werde ich etwas näher auf einige populäre Archivierungs-
programme eingehen. 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 Datei ist. Dieses Archiv
muss auch keineswegs auf ein Band geschrieben werden, es kann auch als
normale Datei in einem Filesystem gespeichert werden. Umgekehrt kann man
die Archivdatei als solche auch einfach mit cat(1) vom Band kratzen.
Bei den diversen Archivierungsprogrammen stößt man immer wieder auf eine
Blockgröße und im Netz finden sich oft auch Überlieferungen, auf Bänder
mit dd(1) und einer bestimmten Blockgröße zuzugreifen. Offenbar gab
(gibt?) es Bandlaufwerke und Treiber, bei denen die Größe eines write(2)
die Länge des Datenblocks auf dem Band bestimmt, und allerlei damit
verbundene Einschränkungen beim Lesen und Schreiben entstehen, z.B. dass
Bänder mit derselben Blockgröße gelesen werden müssen, mit der sie
geschrieben worden sind. Mir ist dieser Effekt bisher in der Praxis noch
nicht begegnet, ich ignoriere erfolgreich den Aspekt der Blockgröße
komplett.
tar
--- Sehr beliebt ist tar(1), der Tape ARchiver. Tatsächlich ist die gängigste Anwendung von tar heute gar nicht mehr das Sichern von Daten auf Band, sondern es wird als allgemeines Archivierungswerkzeug zum Bündeln von Dateibäumen zu einer einzelnen Archivdatei eingesetzt. Viele Unix-Neulinge kennen es nur in dieser Funktion und sind dann gehörig verdutzt, wenn sie tar aus Versehen ohne -f aufrufen, woraufhin es aus der (in die) eincompilierte Defaultdatei liest (schreibt), was je nach System alles Mögliche sein kann (/dev/rmt8, stdout, etc.).tar packt selbständig rekursiv Dateibäume ein, so dass man ihm typischerweise einen oder mehrere Verzeichnisnamen übergibt. Mittels Option ("-l" bei GNU tar) kann man ihn 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.
Beachtenswertes:
- 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.
- Auch die Archivformate können abweichen. Ich hatte damit bisher in der Praxis noch keine Probleme, die Situation ist undurchsichtig.
- 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 steckt von alleine alle Informationen über eine Datei ins Archiv. Nur beim Rücklesen eines Backups ist "-p" notwendig, um alle Rechte originalgetreu zu restaurieren.
- Man packt *nie* 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. HP-UX) ist man auf den Pfad im Archiv festgelegt.
cpio ---- Während tar(1) eher in der BSD-Ecke heimisch zu sein scheint, erfreut sich cpio(1) (CoPy In/Out) mehr bei System V Bekannt- und Beliebtheit. Es hat prinzipiell eine ähnliche Funktionalität wie tar, nur eine völlig andere Aufrufsyntax. Beim Erstellen eines Archivs liest cpio nicht selbständig ganze Dateibäume sondern erwartet eine Liste aller Datein auf stdin, wird also typischerweise in der Form "find ... | cpio ..." aufgerufen.
Beachtenswertes:
- Auch hier gilt, nicht jedes cpio ist ein GNU cpio.
- cpio stellt typischerweise mehrere Archivformate zur Verfügung, darunter auch welche von tar, wobei der Default oft heute unakzeptable Beschränkungen auf 16-Bit i-Node- 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 "-H newc" oder "-H crc" praktisch Pflicht.
- Wenn man cpio-Archive zwischen verschiedenen Rechnern portieren will, sollte man auch beachten, dass das Format auf beiden Seiten verstanden wird.
- cpio hat eine ganze Reihe von Optionen, die das Restaurieren von Eigentümern, Rechten, und Anlegen von Verzeichnen beim Extrahieren von Archiven betreffen. Die Defaults sind *nicht* zum Rückspielen eines Backups geeignet.
- Auch hier gilt wieder, keine absoluten Pfade verwenden.
pax --- Dritter im Bunde neben tar(1) und cpio(1) ist pax(1), das die POSIX- Schöpfer sich ausgedacht haben. pax ist relativ unbekannt, unterstützt ebenfalls eine vergleichbare Funktionalität wie tar und cpio und bringt die dritte völlig andere Benutzerschnittstelle mit. Nicht ganz zufällig sind auf OpenBSD tar, cpio, und pax Links auf dasselbe Executable, das sich nur, je nachdem wie es aufgerufen wurde, mit entsprechend anderer Benutzerschnittstelle gibt.
Für die Archivformate gelten ähnliche Hinweise wie bei cpio. Interessant ist bei pax die Möglichkeit, beim Extrahieren die Dateinamen mit einem Regular Expression umzuschreiben.
Puffern ------- Ähnlich wie sich tar, cpio, und pax trotz aller äußerlichen Unterschiede sind, teilen sie sich auch ein Problem. Sie bestehen alle aus einem Prozess, der abwechselnd die Daten vom Dateisystem kratzt und ein Stück Archivdatei schreibt. Dabei entstehen ausgabeseitig Pausen und ein Bandlaufwerk läuft nicht unterbrechungsfrei durch, es "streamt" nicht. Das ist ärgerlich, weil das Bandlaufwerk jedesmal, wenn der Datenstrom abreißt, ein Stück zurückspulen und neu aufsetzen muss. Das ist laut, verschleißintensiv für Band und Laufwerk, und der Gesamtdurchsatz bricht ein.
Abhilfe schafft hier eine externe Pufferung. Gängig sind buffer(1) und team(1), die leider normalerweise nicht zur Grundinstallation eines Betriebssystems gehören. buffer benutzt ein bis zu 1MB großes Segment System-V-Shared-Memory, was man auf BSD-Rechnern erst in den Kernel konfigurieren muss, team kommt mit Pipes aus. buffer und team zerlegen sich in lesende und schreibende Prozesse und glätten den Ausgabestrom, so dass das Bandlaufwerk gleichmäßig durchlaufen kann, wenn tar & Co. die Daten nur im Zeitmittel schnell genug liefern. Ein Aufruf sieht dann z.B. so aus: "tar clf - /usr | buffer -o /dev/nst0". buffer ist bei Debian GNU/Linux als Paket verfügbar.
Ein Nachteil einer zusätzlichen Pufferung ist, dass ein Backup auf mehrere Bänder (volumes), grundsätzlich schon problematisch, nun nicht mehr möglich ist. Einem oft empfohlenen Tip, tar etc. mit einem nachgeschalteten dd(1) zu puffern, kann ich mich nicht anschließen. Sofern das überhaupt etwas bringt, ist es buffer oder team hoffnungslos unterlegen.
dump ---- *Das* Backupwerkzeug überhaupt, insbesondere in der BSD-Welt, ist die Kombination dump(8) und restore(8), auf Solaris "ufsdump". Für Linux gab es das lange Zeit nicht, aber mittlerweile ist eine Portierung von BSD4.4 dump/restore für ext2 auch schon seit einigen Jahren verfügbar.
Für Backups ist dump das Beste seit geschnittenem Brot. Es sichert ganze Dateisysteme, kann inkrementelle Sicherungen, ist schnell, zuverlässig, kann mehrere Bänder verwalten, und puffert selbständig. Zum Restaurieren von Daten verwendet man restore. Hier hat man, neben der Wiederherstel- lung eines kompletten Dateisystems und einzelner Dateien/Verzeichnis- bäume von der Kommandozeile aus, auch Zugriff auf einen interaktiven Modus, in dem man sich mit cd und ls durch das gesicherte Dateisystem hangeln und einzelne Dateien/Verzeichnisse zurücklesen kann.
Was die Portabilität von dump-Archiven angeht - 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 - so habe ich keine verlässlichen Angaben bekommen können. Empirisch kann ich feststellen, dass Linux/i386 und FreeBSD/i386 trotz der verschiedenen Dateissysteme (Ext2fs <-> FFS) mit den Archiven des jeweils anderen keine Probleme haben. Linux/i386 scheint auch mit Solaris/sparc (andere Bytefolge!) zurechtzukommen.
Remote Backup ------------- Wer zu Hause mehr als einen Rechner hat, oder an Uni/Arbeitsplatz/etc. eine kleine Arbeitsgruppe, der möchte natürlich nicht jedem Rechner ein eigenes Bandlaufwerk spendieren. Also bietet es sich an, Backups übers Netz zu fahren, wo doch die schönen 10, 100, oder 1000 Mbit/s nachts völlig brach liegen.
Es ist naheliegend, das Archivierungsprogramm auf stdout (von stdin) schreiben (lesen) zu lassen, und die Übertragung zum Tape-Host über rsh(1) oder ssh(1) abzuwickeln, wo dann ein simples cat(1) aufs Band zugreift. Sinnvollerweise kann man dort auch eine Pufferung mit buffer oder team verwenden.
Dabei sei angemerkt, dass man den CPU-Bedarf von ssh auf langsamen Rechnern nicht unterschätzen sollte. Ich habe letzte Woche angefangen den OpenBSD-Source-Baum von einer auf einem anderen Rechner gemounteten CD mit (sinngemäß) "ssh HOST tar -cf - -C /mnt/cdrom src | tar xpf -" auf eine SPARCstation IPC (25MHz SPARC, ca. i386-Klasse) zu übertragen. Die Load des sonst unbelasteten Rechners ging auf 2, ssh hat die meiste CPU gezogen, tar kaum. Oops. Ich habe es dann doch mit rsh gemacht.
GNU tar, GNU cpio, und dump unterstützen auch direkt den Zugriff auf ein Bandlaufwerk auf einem anderen Rechner am Netz, indem man als Zieldatei einfach <Host>:<Device> angibt. Das setzt für Backupzwecke allerdings root-Zugriff über rsh voraus, was je nach Umgebung nicht akzeptabel ist. Bei tar/cpio fehlt dann auch wieder die Pufferung, für dump ist das allerdings bequem. Auf dem Zielrechner wird /etc/rmt gestartet, dem mit einem einfachen Protokoll Lese-/Schreibbefehle übermittelt werden.
Amanda ------ Hat man einen kleinen Rechnerverbund und möchte regelmäßige, auto- matische 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 Tape-Host, an dem sich das Bandlaufwerk befindet, und auf dem der Server installiert wird. Auf den zu sichernden Rechnern ist der Client zu installieren.
Von cron angestoßen fragt der Serverhosts der Reihe nach die Clienthosts ab, und lässt sich von ihnen volle und inkrementelle Backups mittels dump (oder GNU tar) schicken. Kerberos wird unterstützt, so vorhanden. Zentral konfiguriert wird, welche Dateisysteme von welchen Hosts 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) restore-artig bequem angeben kann, welche Dateien von welchem Datum man von welchem Host haben möchte, und Amanda sagt einem dann welche Bänder einzulegen sind und holt die Daten zurück.
Tolles Paket für mittlere Backup-Bedürfnisse.
Mein Backup ----------- Was verwende ich hier zu Hause? Meine Konfiguration:
"mips" 10M "bigeye" AM386-40 ----------------------- i586-100 Linux Ethernet FreeBSD | 1.2GB QIC Streamer
Ich muss gestehen, ich habe auch erst in den letzten Wochen dump "entdeckt". Vorher habe ich tar und cpio verwendet. tar auf mips, weil ich tar gewohnt bin. cpio auf bigeye, weil der dortige GNU tar die 32-Bit Devicenummern von FreeBSD nicht abkann. Ich hatte wie selbst- verständlich angenommen, dass dump-Archive aufgrund der verschiedenen Dateisysteme nicht zwischen diesen beiden Rechnern kompatibel sein würden, und ich möchte die Backups des einen auf dem anderen lesen können.
Da die Daten noch auf jeweils ein Band passen, ziehe ich der Einfachheit halber ca. wöchentlich ein Vollbackup und erspare mir inkrementelle Sicherungen. Um das Laufwerk am streamen zu halten, kam buffer zum Einsatz. Ein Einsatz von rsh, auch als root, ist hier im lokalen Netz unproblematisch. Damit ergaben sich dann folgende Backup-Skripte:
-----mips------>
TAPE=/dev/nst0 cd / tar -clf - . | buffer -o $TAPE tar -clf - usr | buffer -o $TAPE tar -clf - home | buffer -o $TAPE tar -clf - var --exclude=/var/spool/news | buffer -o $TAPE
echo -n "Rewinding... " mt -f $TAPE offline echo "done." <---------------
Den Newsspool zu sichern lohnte nicht, außerdem bricht bei den vielen kleinen Dateien der Durchsatz völlig ein. Wer einen ansatzweise ernsthaften Newsserver fährt, hat den Newsspool natürlich ohnehin auf einer eigenen Partition, aber für mein Heimsystem hier habe ich darauf verzichtet.
-----bigeye----> host=mips tape=/dev/nst0
cd / find -dx . -print | cpio -oH crc | rsh $host buffer -o $tape find -dx usr -print | cpio -oH crc | rsh $host buffer -o $tape find -dx home -print | cpio -oH crc | rsh $host buffer -o $tape find -dx var -print | cpio -oH crc | rsh $host buffer -o $tape echo -n "Rewinding... " rsh $host mt -f $tape offline echo "done." <---------------
Mittlerweile, nachdem sich die Portabilität der Archive erwiesen hat, verwende ich durchgehend dump:
-----mips------> -----bigeye----> host=mips TAPE=/dev/nst0 tape=/dev/nst0
dump 0f - / >$TAPE dump 0af $host:$tape / dump 0f - /usr >$TAPE dump 0af $host:$tape /usr dump 0f - /home >$TAPE dump 0af $host:$tape /home dump 0f - /var >$TAPE dump 0af $host:$tape /var
echo -n " Rewinding... " >&2 echo -n " Rewinding... " >&2 mt -f $TAPE offline rsh $host mt -f $tape offline echo "done." >&2 echo "done." >&2 <--------------- <---------------
Da dump nur ganze Filesysteme sichert, kann ich hier den Newsspool auf mips:/var nicht ausnehmen. Zu meiner großen Überraschung ist das aber auch nicht notwendig. dump ist auch bei den vielen kleinen Dateien ausreichend schnell, um das das Band am laufen zu halten. Mein Respekt vor diesem Programm wächst weiter.
Die historisch gewachsene, gut gemeinte, aber lästige, in dump integrierte Bandlängenberechnung schalte ich unter Linux dadurch ab, dass ich dump nach stdout schreiben lasse, unter FreeBSD gibt es dafür das neu hinzugekommene Flag "-a".
So einfach ist das.
-- Christian "naddy" Weisgerber naddy_at_mips.rhein-neckar.de >H Deutsche Transhumanismus-Mailingliste echo 'subscribe trans-de' | mail majordomo_at_lists.rhein-neckar.de
Dieses Archiv wurde generiert von hypermail 2.1.2 : 11. Mar 2002 CET