Inhaltsverzeichnis
Beschreibung: Prüfungskandidaten sollten in der Lage sein, eine Sicherungsstrategie zu planen und Dateisysteme automatisch auf verschiedene Medien zu sichern. Die Tätigkeiten beinhalten das Sichern einer rohen Partition in eine Datei oder umgekehrt, das Durchführen teilweiser und manueller Backups, das Überprüfuen der Integrität von Backupdateien und teilweises oder vollständiges Wiederherstellen von Backups.
Die wichtigsten Dateien, Bezeichnungen und Anwendungen:
- cpio
- dd
- dump
- restore
- tar
Dieser Abschnitt der LPI 102 Prüfung erfordert nicht nur das Wissen um die konkrete Syntax einzelner Befehle, sondern auch die grundsätzliche Architektur von Backup-Strategien. Backups werden heute mit den unterschiedlichsten Programmen erstellt und auf unterschiedlichsten Medien abgelegt. Die genaue Syntax aller hier denkbarer Programme ist sicherlich etwas, was den Rahmen sowohl der LPI-Prüfung, als auch dieser Darstellung sprengen würde. Die wichtigsten Bordmittel werden aber hier genau besprochen.
Vorüberlegungen
Grunsätzlich ist zu sagen, daß ein Backup auf jedem Rechner notwendig ist, dessen Dateien nicht rein statisch sind. Ein Rechner, der etwa nur als Router ins Internet Dienst tut, muß sicherlich kein regelmäßiges Backup ausführen, hier würde die einmalige Sicherung nach der abschließenden Konfiguration ausreichen. Jeder Rechner, auf dem gearbeitet wird, dessen Dateien also nicht statisch sind, muß aber regelmäßige Backups erledigen, um die getane Arbeit zu sichern. Wie im einzelnen die Backups aussehen, was gesichert wird, das muß gründlich geplant werden.
Ein wesentliches Kriterium für ein Backup ist die Frage, auf welches Medium die gesicherten Daten gespeichert werden sollen. Es bietet sich grundsätzlich an, Wechselmedien zu benutzen, die an einem anderen Ort gelagert werden können. Wird ein Backup nur auf eine zweite Platte im Rechner gemacht, so haben wir vielleicht eine Absicherung gegen eine physikalische Zerstörung der Platte (Headcrash), Feuerschäden, Wasserschäden oder Diebstahl des Rechners würde diese Form des Backups nicht abdecken, die Daten wären verloren.
Wechselmedien stehen in verschiedenen Formen zur Verfügung. Neben Wechselplatten, die auf der Festplattentechnik beruhen, sind es meist Bandlaufwerke, die für Backups verwendet werden. Hier spielen drei wesentliche Familien eine Rolle, Viertelzoll-Cartridges (QIC), DAT-Cassetten und Videobänder.
Die Speicherkapazität eines Backup-Mediums ist von großer Bedeutung. Muß das Medium während des Backups gewechselt werden, weil es nicht genügend Speicherplatz aufweist, so kann ein Backup nicht vollständig automatisiert werden. Der Aufwand (und damit auch die Hemmschwelle) ist wesentlich größer, als bei einem Medium, das das ganze Backup in einem Rutsch aufnehmen kann.
Die Frage, was überhaupt gesichert werden muß, ist die nächste Überlegung. Wir unterscheiden zwischen verschiedenen Backup-Strategien. Insbesondere zwei Begriffe werden hier immer wieder fallen: volles Backup und inkrementelles Backup.
Ein Vollbackup ist ein Backup, das alle Daten, die gesichert werden müssen, in einem Arbeitsgang auf ein Medium speichert. Ein inkrementelles Backup speichert im Gegensatz dazu nur die Daten, die sich seit dem letzten Backup verändert haben. Ein inkrementelles Backup ist nur in Zussammenarbeit mit einem Vollbackup möglich!. Abhängig von der Sicherheitsanforderung kann z.B. überlegt werden, jeden Tag der Woche ein inkrementelles Backup vorzunehmen, und Freitags ein Vollbackup. Das bedingt aber, daß alle Medien, die diese Backups aufgenommen haben, zu einer Wiederherstellung (restore) der Daten benötigt werden.
Nehmen wir ein Beispiel: Wir haben folgenden Backup-Plan:
- Montag – inkrementelles Backup – Band 1
- Dienstag – inkrementelles Backup – Band 2
- Mittwoch – inkrementelles Backup – Band 3
- Donnerstag – inkrementelles Backup – Band 4
- Freitag – volles Backup – Band 5
Es ist jetzt Mittwoch, wir haben einen Headcrash, der uns zwingt, alle Daten auf eine neue Platte aufzuspielen. Wie müssen wir vorgehen?
Die Reihenfolge des Wiederaufspielens ist hier wichtig. Wir brauchen:
- Das Band mit dem letzten Vollbackup (Band 5)
- Die Bänder der letzten inkrementellen Backups vom letzten Vollbackup bis zum Eintreten der Katastrophe. Also in unserem Beispiel die Bänder von Montag und Dienstag (Band 1 und 2)
Das Wiederaufspielen muß jetzt in genau der Reihenfolge passieren, wie das Backup selbst. Zunächst spielen wir die Daten des Vollbackups wieder auf die Platte, dann die des Montag-Bandes und erst dann die des Dienstag-Bandes. Nur so stellen wir sicher, daß wir nicht alte Versionen von Dateien aufspielen, die die neueren wieder überschreiben…
Das ist ein aufwendiges Verfahren, das in der Praxis selten vorkommt. Um variabel mit Kombinationen von vollen und inkrementellen Backups arbeiten zu können, werden sogenannte Backup-Level definiert. Dabei wird ein Vollbackup immer Level 0 genannt, ein inkrementelles Backup hat dann Levelnummern größer als 0. Jedes inkrementelle Backup, egal welche Levelnummer es trägt, sichert immer alle Daten, die sich seit dem letzten Backup mit einer Nummer niedriger verändert haben. Ein Beispiel:
- Erster Montag des Monats
Level 0 (Vollbackup) - Jeder andere Montag
Level 1 (wöchentliches inkrementelles Backup relativ zu Level 0) - Dienstag
Level 2 (tägliches inkrementelles Backup relativ zu Level 1) - Mittwoch
Level 2 (tägliches inkrementelles Backup relativ zu Level 1) - Donnerstag
Level 2 (tägliches inkrementelles Backup relativ zu Level 1) - Freitag
Level 2 (tägliches inkrementelles Backup relativ zu Level 1)
In diesem Fall brauchen wir für ein Wiederherstellen (restore) der Daten immer nur das aktuellste Band von jedem Level. Da jeder Level über 0 immer alle Daten sichert, die seit dem letzten Backup des vorgehenden Levels verändert wurden hat z.B. das Donnerstagsband immer auch die Daten gespeichert, die am Mittwoch verändert wurden. Es speichert ja alle Daten, seit dem letzten Backup mit niedrigerer Nummer, also seit Montag.
Zum Wiederherstellen der Daten nach einer Katastrophe am Freitag brauchen wir also
- Das letzte Vollbackup (Level 0)
- Das letzte inkrementelle Wochenbackup (Level 1)
- Das letzte inkrementelle Tagesbackup vom Donnerstag (Level 2)
Das Wiederaufspielen der Daten erfolgt jetzt in genau dieser Reihenfolge; zuerst das Vollbackup, dann Level 1 und erst dann Level 2. Jetzt ist garantiert, daß immer die aktuellsten Versionen der Dateien wiederaufgespielt sind.
Planung von Backups
Bei der Planung einer Backup-Strategie müssen ein paar Fragen durchüberlegt werden, deren Beantwortung das Backup leichter planbar machen. Wenn wir schon bei der Planung der Architektur des ganzen Systems auf solche Kriterien achten, können wir uns das Leben wesentlich erleichtern.
Die wichtigste aller Fragen ist die, welche Dateien überhaupt gesichert werden müssen. Bei einer vernünftigen Planung eines Systems können einige Teilbereiche des Systems völlig statisch angelegt werden. Das kann seinen Ausdruck dann darin finden, daß ganze Partitionen Read-Only gemountet werden, so daß selbst versehentliche Änderungen nicht möglich sind. Ein Beispiel hierfür ist die Tatsache, daß das /usr-Verzeichnis geradezu dafür gemacht ist, nur lesend eingehängt zu werden. Solche Bereiche können wir einmal – direkt nach der Installation – sichern und müssen sie dann nie wieder in unsere Backup-Überlegungen aufnehmen…
Eine weitere Überlegung beim Aufbau des Systems ist die, wo die User eines Systems Daten ablegen dürfen und wo nicht. Gibt es hier strenge Richtlinien, die etwa festlegen, daß User ihre Daten grundsätzlich nur in ihren Home-Verzeichnissen ablegen dürfen und diese Homeverzeichnisse auf einer separaten Partition liegen, dann ist durch das Backup dieser einen Partition schon der wesentliche Datenbesatz gesichert. Die Daten der User sind auf alle Fälle nicht verloren.
Ein weiterer wichtiger Bereich, der immer Teil des Backups sein sollte, ist der Bereich der Systemkonfigurationsdateien in /etc. Diese Konfiguration ist vielleicht nicht so hochdynamisch wie der Userdatenbereich, aber er enthält doch auch einige Daten, die sich oft verändern können. Neue oder veränderte Passwörter, die gesammte Arbeit der Systemkonfiguration usw. Um zu vermeiden, daß ein zu großer Datenbestand gesichert werden muß, ist es auch möglich, ein Verzeichnis auf einem Dateisystem anzulegen, das regelmäßig im Backup aufgenommen wird (z.B. /home). Dann wird ein Shellscript erstellt, das alle wichtigen Systemkonfigurationen aus /etc dorthin kopiert. Etwas wie
#!/bin/bash cp /etc/passwd /home/backup cp /etc/shadow /home/backup cp /etc/group /home/backup cp /etc/gpasswd /home/backup cp /etc/fstab /home/backup ...
Dieses Script sollte jetzt täglich von cron aufgerufen werden. Damit ist sichergestellt, daß die wichtigsten Konfigurationsdateien ins Backup aufgenommen sind.
Backup mit dump
Das Programm dump bietet alle Funktionalität, um entweder ganze Dateisysteme (Partitionen) oder einzelne Verzeichnisse in ein Backup aufzunehmen. Die ursprüngliche Version von dump kommt aus der BSD Unix Welt, das Linux-Dump Programm ist aber eine eigene Version, die speziell für das EXT2 Dateisystem geschrieben wurde. Es gibt heute aber auch schon Versionen für weitere Dateisystemtypen, insbesondere für das ReiserFS.
Dump untersucht Dateien eines Dateisystems und entscheidet, welche Dateien in ein Backup aufgenommen werden müssen. Diese Dateien werden dann auf das angegebene Backup-Medium geschrieben, das entweder eine Platte, ein Band oder eine Datei sein kann. (Einstellbar mit der -f Option)
Passt das Backup nicht auf das angegebene Medium, so fordert dump zu einem Medienwechsel auf, und verteilt das Backup auf mehrere solcher Medien.
Dump unterstützt 10 Backup-Level (0-9), wobei wie oben beschrieben das Level 0 ein Vollbackup meint und jedes weitere Level ein inkrementelles Backup relativ zum letzten Backup des nächst-niedrigeren Levels bedeutet. Die grundsätzliche Aufrufform von dump ist
dump [-Level] [-u] [-f Backupdatei] Dateisystem
oder
dump [-Level] [-u] [-f Backupdatei] Verzeichnis
Wobei meist also zuerst das Backup-Level angegeben wird (0-9), gefolgt von einem u (update /etc/dumpdates). Mit der Anweisung -f Backupdatei wird das Medium gewählt. Hier steht also entweder eine Gerätedatei des verwendeten Bandlaufwerks oder ein Dateiname, der Datei, die das Backup aufnehmen soll. Die abschließende Angabe des Dateisystems oder Verzeichnisses gibt an, was gesichert werden soll.
Passt das Backup nicht auf das angegebene Medium, so fordert dump zu einem Medienwechsel auf, und verteilt das Backup auf mehrere solcher Medien.
Die Datei /etc/dumpdates speichert die Daten alle bisherigen Backups in der Form:
/dev/hda8 0 Sat May 5 21:56:49 2001 /dev/hda8 1 Mon May 7 21:55:58 2001 ...
Hier zeigt sich also, daß die Partition /dev/hda8 am Samstag, den 5. Mai 2001 um 21:48 Uhr ein Vollbackup (Level 0) erhalten hat, während am darauffolgenden Montag ein inkrementelles Backup (Level 1) ausgeführt wurde.
Der Aufruf
dump -0ua -f /dev/tape /dev/hda8
hatte das erste dieser beiden genannten Backups erstellt, das zweite wurde mit
dump -1ua -f /dev/tape /dev/hda8
erstellt.
Es sei hier an dieser Stelle noch einmal ausdrücklich an die Datei /etc/fstab erinnert, deren fünftes Feld die Frage klärt, ob die jeweilige Partition von dump bearbeitet werden soll, oder nicht.
Daten wiederherstellen mit restore
Das Gegenstück zum Programm dump ist restore, mit dem sich Daten von einem Backup-Medium wiederherstellen lassen. Dieses Programm hat sehr viele verschiedene Anwendungen, die alle mit Kommandozeilenparametern einstellbar sind. Die wichtigsten Aktionen für die wir dieses Programm brauchen sind nicht nur das Wiederherstellen von Daten, sondern auch der Vergleich eines Backups mit dem Orginaldatenbestand. Damit können wir bei wichtigen Backups die Konsistenz des Backups überprüfen.
Wichtige Aufrufformen von restore sind:
restore -C -f Datei
restore -i -f Datei
restore -r -f Datei
restore -x -f BackupDatei Datei1 Datei2 ...
Restore ist also das Programm, mit dem alle Bearbeitung der bereits gemachten Backups vorgenommen werden, insbesondere die Wiederherstellung der gesicherten Dateien.
Ist ein Backup auf mehrere Medien verteilt, so fordert restore zum gegebenen Zeitpunkt zum Medienwechsel auf..
Partielle und manuelle Backups mit tar
Um schnell ein Verzeichnis oder ein paar Dateien zu sichern ist die Anwendung von dump und restore sicherlich übertrieben. Hier findet das Programm tar seine Anwendung. tar steht für Tape Archiver, ist also grundsätzlich auch gedacht gewesen, Backups auf Bandlaufwerke zu schreiben. Heute wird tar aber sehr häufig eingesetzt, um Verzeichnisse oder Dateien in eine Archivdatei zu packen, die dann auf anderen Medien abgespeichert werden kann oder auch an andere User weitergegeben werden kann. Vor der Einführung der modernen Paket-Manager (RPM, DPKG) war das tar-Format das bestimmende Format für Linux-Distributionen.
Tar wird sowohl zum Erstellen, als auch zum Entpacken von Archiven benutzt. Es ist also kein zusätzlicher Entpacker wie etwa restore nötig.
Wie schon dump und restore kennt auch tar die Option -f Dateiname mit der angegeben wird, welche Datei als Medium zum Speichern (oder entpacken) des Archivs verwendet werden soll. Auch hier kann entweder eine Gerätedatei eines Bandlaufwerks, eine reguläre Datei oder ein Bindestrich (für StdIn bzw StdOut) angegeben werden.
Tar selbst nimmt keinerlei Komprimierung vor, arbeitet jedoch gerne mit dem gzip-Programm zusammen. Musste man früher die Archivdatei noch manuell komprimieren, so kennt tar heute die Optionen -z (komprimieren oder dekomprimieren mit gzip) und -Z (komprimieren oder dekomprimieren mit compress – veraltet) um selbstständig gleich gepackte Archive zu erstellen oder zu entpacken. Die jeweiligen Programme gzip und compress müssen dazu aber vorhanden sein, tar ruft sie nur auf, es kann selbst keine Kompression vornehmen.
Die normale Endung einer Archivdatei, die mit tar hergestellt wurde heisst in der Regel .tar – wurde das Archiv mit gzip komprimiert trägt es standardmäßig die Endung .tar.gz oder (um auch DOS-konform zu sein) .tgz. Wurde die Archivdatei mit compress komprimiert, so endet ihr Name meist auf .tar.Z
Die drei wichtigsten Funktionen von tar sind
- Erstellen (create) von Archiven (-c)
- Inhaltsverzeichnis (table of content) von Archiven anzeigen (-t)
- Archive entpacken (extract) (-x)
Um ein Archiv mit dem Namen Test.tgz anzulegen, das mit gzip komprimiert ist und alle Dateien des Verzeichnisses Testdir enthält, rufen wir tar folgendermaßen auf:
tar -czf Test.tgz Testdir
Um den Inhalt dieses frisch geschaffenen Archivs anzusehen schreiben wir:
tar -tzf Test.tgz
Und um das Archiv im aktuellen Verzeichnis wieder zu entpacken ist der Befehl
tar -xzf Test.tgz
nötig. Wird zusätzlich noch die Option -v angegeben, so arbeitet tar „geschwätzig“ (verbose), gibt uns also mehr Informationen mit. Insbesondere beim Ansehen des Inhaltsverzeichnis ist das eine gute Idee. Aber vorsicht: Der erste Parameter von tar legt die Aktion fest (c oder t oder x), die Parameter v und z folgen beliebig. Der f-Parameter kommt am Schluß, denn ihm folgt der Dateiname.
Archive mit cpio bearbeiten
Anstelle von tar kann auch das Programm cpio verwendet werden, um Archive zu erstellen oder zu bearbeiten. cpio kann dabei verschiedene Formate – unter anderem auch das tar-Format – bearbeiten. Ein großer Vorteil von cpio ist der, daß die Liste der zu archivierenden Dateien nicht auf der Kommandozeile (wie bei tar) erwartet wird, sondern auf der Standard-Eingabe. Dadurch ist es möglich, die Ergebnisse etwa des find-Befehls direkt an cpio weiterzupipen und so ein Archiv mit den Suchergebnissen aufzubauen.
cpio arbeitet in drei verschiedenen Modi:
- copy-out
Dateien werden in ein Archiv geschrieben (out meint die Ausgabe in ein Archiv) - copy-in
Dateien werden aus einem Archiv extrahiert (in meint die Eingabe ins Dateisystem) - copy-pass
Dateien werden von einem Ort zu einem anderen kopiert, quasi eine Kombination aus copy-out und copy-in, ohne jedoch tatsächlich ein Archiv zu erstellen.
Durch die Verwendung unterschiedlicher Formate und die Fähigkeit die zu archivierenden Dateien sowohl aus einer Dateiliste, als auch von der Standard-Eingabe zu lesen, ist cpio wesentlich flexibler als tar. Allerdings ist es auch um einiges komplizierter anzuwenden.
Ein- und Ausgabe mit dd
Um Dateien beliebiger Art (in unserem Fall speziell Archivdateien) von und auf Gerätedateien zu kopieren, existiert das sehr nützliche (und sehr häufig verwendete) Programm dd. dd steht für DiskDump und ermöglicht es, Daten von Gerätedateien zu regulären Dateien zu kopieren oder umgekehrt. Es ist natürlich auch möglich, von Gerätedatei zu Gerätedatei zu kopieren. Die grundsätzliche Form ist dabei
dd if=Eingabedatei of=Ausgabedatei bs=Blockgröße count=Anzahl
Dieser Befehl kopiert Anzahl Blöcke der Größe Blockgröße aus der Eingabedatei in die Ausgabedatei. Dabei können sowoh Ein-, als auch Ausgabedatei entweder Gerätedateien oder reguläre Dateien sein. Wird die Angabe der Blockgröße weggelassen, so werden die „natürlichen“ Blockgrößen der jeweiligen Geräte verwendet. Wird die Anzahl der zu lesenden Blöcke weggelassen, so werden alle Blöcke der Datei (oder des Gerätes) gelesen. So kann z.B ein komplettes Image einer Festplatte oder Partition (oder Diskette oder CDROM) in eine Datei durch den Befehl
dd if=Gerätedatei_des_Laufwerks of=Imagedateiname
erstellt werden. Mit dem umgekehrten Befehl
dd of=Gerätedatei_des_Laufwerks if=Imagedateiname
wird das entsprechende Image wieder auf das Gerät geschrieben.
Durch die Angabe von ibs= (Input-Blocksize) und obs= (Output-Blocksize) kann sogar noch zwischen verschiedenen Blockgrößen bei Ein- und Ausgabe unterschieden werden.
Zusätzlich kann dd auch noch Konvertierungen der zu kopierenden Blöcke vornehmen, wie etwa die Reihenfolge der Bytes in einem Datenwort oder Klein-Großschreibung.
Für die Backup-Technik ist dd besonders interessant, weil damit Archivdateien direkt auf Band geschrieben werden können oder von Bändern gelesen werden können.