Druckversion | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Die regelmäßige Sicherung des Datenbestandes zählt zu den wichtigsten Aufgaben eines Systemverwalters. Ein Datenverlust kann verschiedene Ursachen haben. Sei es durch einen Hardwareausfall, durch einen Softwarefehler, sei der Grund eine Fehlbedienung oder ein Virus oder es zeichnet sich gar eine dubiose Gestalt mit böswilligen Manipulationen dafür verantwortlich. Nach Murphy's Gesetz ereilt einen das Schicksal stets im unpassendsten Augenblick. Glück für denjenigen, der durch eine besonnene Strategie der Datensicherung den Schaden in Grenzen halten konnte. Die Begriffe »Backup« und »Archiv« verwenden wir im weiteren Verlauf synonym. Allgemein bezeichnen wir als ein Archiv einen Container von Daten, der aufbewahrt wird, um genau auf diese Daten später zugreifen zu können. Archive legt man an, um momentan nicht benötigte Daten von der Festplatte zu verbannen oder um sie von einem Rechner auf einen anderen zu kopieren... Die Motivation zu einem Backup resultiert aus anderen Überlegungen. Hier ist die Absicht, einen bestimmten Systemzustand aufzuzeichnen. Dabei bezieht man sich nicht auf den konkreten Inhalt einer Datei - wie bei Archiven - sondern ordnet eine Datei in die Schublade »wichtig« oder »unwichtig« ein, je nachdem, ob sie von meiner Backupstrategie betroffen sein wird oder nicht. Grundsätzlich werden zwei Arten des Backups unterschieden. Das volle Backup sichert stets den kompletten Bestand an Daten, während das inkrementelle Backup nur Daten archiviert, die innerhalb einer bestimmten Periode modifiziert wurden. Dabei steht die Periode meist für den Zeitraum seit der letzten Sicherung. Ein volles Backup ist wegen des hohen Bedarfs an Zeit (die Sicherung erfolgt meist auf ein Bandmedium) weniger für den täglichen Einsatz geeignet, deswegen entscheidet man sich heute meist für eine Mischform aus voller und inkrementeller Datensicherung. Hierbei wird zu einem Zeitpunkt der komplette Datenbestand gesichert und nachfolgend - in regelmäßigen Abständen - archiviert man nur die modifizierten Daten. Die tatsächlich gewählte Strategie des inkrementellen Backups hängt stark von der »Statik« der Daten und vom Sicherheitsbedürfnis des Administrators ab. Im einfachsten Fall betrifft das Backup jeweils alle modifizierten Daten seit dem letzten vollen Backup bis hin zum aktuellen Zeitpunkt. Das umgekehrte Verfahren ist die Aufzeichnung der Änderungen seit der letzten inkrementellen Sicherung. Während in ersterem Fall nur die Archive des vollen und letzten inkrementellen Backups aufbewahrt werden müssen, sind beim zweiten Vorgehen das volle Backup und sämtliche inkrementellen Datensicherungsarchive aufzuheben. In der Praxis findet man auch Archivierungsformen zwischen den beiden beschriebenen Extremen (Multilevel-Backups). Bedenken Sie, dass ein Festplattenfehler Sie auch während der Aufzeichnung eines Backups ereilen kann. Überschreiben Sie daher niemals ihre aktuelle Sicherungskopie. Bei der Vorstellung der Backup-Werkzeuge beschränken wir uns auf Programme, die der GPL oder einer ähnlichen Lizenz unterstehen. In vielen Fällen lassen sie die Bedienfreundlichkeit kommerzieller Produkte vermissen, jedoch ist es durchaus möglich - die notwendigen Kenntnisse vorausgesetzt - diese in Skripten so zu kapseln, dass sie zum einen die Funktionalität und zum anderen die einfache Benutzbarkeit ausgereifter Werkzeuge erreichen.
Wohin mit den ganzen Daten?Zunächst ist einfach nachvollziehbar, dass die Speicherkapazität des Backupmediums dem aufkommenden Datenvolumen entsprechen muss. Ein volles Backup könnte man durchaus auch auf Disketten vornehmen, jedoch wird man des Wechsels sicherlich bald überdrüssig und die Diskette ist selbst schon Quelle des lauernden Datenverlusts. Wer kennt nicht das leidige »Can't read sector xxx.«? Besser geeignet - vor allem bei dem geringeren Datenaufkommen des inkrementellen Backups - sind ZIP-Disketten. Traditionell sind Magnetbänder (Quarter-Inch- und DAT-Streamer) weit verbreitet. Sowohl Kapazität als auch Zuverlässigkeit sprechen für dieses Medium. Leider lässt sich auf einem Band kein Dateisystem einrichten, so dass die Daten mit Hilfe spezieller Programme sequentiell auf dieses abgelegt werden müssen. Im Falle eines »Restores« muss demnach der gesamte Bandinhalt zurückgespielt werden, da ein wahlfreier Zugriff nicht möglich ist. Ein Magnetband muss vor dem Zugriff zurückgespult werden, hierzu nutzt man das Kommando mt mit der Option rewind:
Es ist außerdem möglich, mehr als ein Archiv auf einem Band unterzubringen, immer vorausgesetzt, die Speicherkapazität setzt keine Schranken:
Waren früher die Medien für einem Streamer die preiswerteste Alternative, so geht heute nichts über eine Festplatte. Dem System eigens für die Datensicherung eine eigene Platte zu spendieren, mag auf den ersten Blick befremdend erscheinen, jedoch erhält man für den Preis eines Streamers eine Menge Festplattenspeicher. Die weiteren Vorteile liegen im wahlfreien und wesentlich zügigerem Zugriff. Allerdings schützt die eingebaute Festplatte nur mäßig vor mutwilliger Sabotage, hier kann eine Datensicherung auf einem anderen Rechner (über das Netz) Abhilfe bringen. Die durch RAID-Systeme realisierbare Datenredundanz schützt nur vor Hardwareausfall einer Festplatte, hat also nichts mit einem Backup zu tun! Während sich die »normale« CD-ROM bzw. DVD wegen der nur einmaligen Beschreibbarkeit eher als Medium zur reinen Archivierung eignet, kann die CD-RW und vor allem die DVD-RW durchaus für die alltägliche Datensicherung eingesetzt werden. Allerdings erfordern umfangreiche Backups, die die Kapazität einer einzelnen CD-ROM übersteigen, die Anwesenheit des Administrators.
Es lohnt sich, etwas Zeit in den Plan zu investieren, welche Daten denn überhaupt den Aufwand eines Backups rechtfertigen. Vielleicht beginnen wir mit Daten, die sichere Kandidaten sind. Da wären:
Als Daten, deren Aufzeichnung Sie sich getrost sparen können, sind all jene zu nennen, die ohnehin auf einem anderen Medium vorhanden sind, z.B. die Daten der Linuxdistribution, die auf CD-ROM im Schrank liegen. Ebenso sollten Dateisysteme, die von entfernten Rechnern gemountet wurden, besser von dessen Backup-Strategie erfasst werden. Aber letztlich ist es die Ermessensfrage des Administrators, welche Daten er für sicherungswürdig erachtet. Eine Neuinstallation von Linux hat ja manchmal auch den Vorteil, etwas Ordnung im System zu schaffen..
Der Tape Archiver ist das verbreitetste Werkzeug zur Datensicherung in Unix-Systemen. Ursprünglich rein zur Datenübertragung auf Bänder konzipiert, mit deren Hilfe der Datenaustausch zwischen verschiedenen Computern zu Zeiten fehlender Netzwerke ermöglicht werden sollte, hat sich gerade durch die Eignung von Bändern als Backupmedium das Programm quasi zum Standardwerkzeug für das Backup in kleineren Netzwerken etabliert, trotz des Fehlens einer brauchbaren Unterstützung von inkrementellen Backups. Als Werkzeug zur Archivierung wurde tar im Kapitel Nutzerkommandos bereits vorgestellt. Hier soll nun der Schwerpunkt auf den Einsatz des Kommandos zum Backup von Daten liegen.
tar arbeitet auf Dateiebene, kann also beliebige Dateien und Verzeichnisse in eine einzige Zieldatei verpacken. Zieldatei kann dabei alles bedeuten, was unter Unix als Datei betrachtet wird, also ein Gerät, eine normale Datei, eine Pipe... Die drei wichtigsten Optionen sind c zum Erzeugen eines Archivs, t zum Betrachten des Archivinhalts und x zum Entpacken desselben. Volles Backuptar wird alle angegebenen Dateien (oder rekursiv den Inhalt von Verzeichnissen) in ein Archiv verpacken. Per Voreinstellung versucht das Kommando das Archiv auf einen Streamer zu schreiben (/dev/tape oder /dev/rmt0), ist kein solcher im System installiert, schreibt tar das Ergebnis auf die Standardausgabe. Um das Archiv in einer Datei zu sichern, ist die Option -f Datei zu wählen. Eine angenehme Eigenschaft ist der Umgang mit »Multivolumes« (Option -M). Speichert man z.B. das Archiv auf eine Diskette und reicht deren Speicherkapazität nicht aus, so fordert tar automatisch zum Wechsel des Mediums auf:
Im Beispiel schreibt tar die Daten auf eine (unformatierte) Diskette, weswegen dem Kommando genau mitgeteilt werden muss, wie groß die Speicherkapazität dieser ist (es ist das entsprechende Device anzugeben). Als erstes entfernt tar in allen Pfadnamen den führenden Slash (-P forciert die Verwendung absoluter Pfadnamen), so dass das Archiv bei einem späteren Entpacken an beliebiger Stelle im Dateisystem extrahiert werden kann - bei Beibehaltung der Verzeichnisstruktur. Nachfolgend wird der Benutzer zum Wechsel der Disketten aufgefordert. Alternativ zu »-M« kann mit -L Anzahl der Medienwechsel nach Archivierung von Anzahl Bytes erzwungen werden. Es ist allerdings furchtbar uneffizient, das Archiv unkomprimiert abzulegen. tar kann zum Glück mit mehreren Packern zusammen arbeiten. Mit -z wird das Archiv mit gzip komprimiert; -Z nutzt das (veraltete) Werkzeug compress und -j (alt: -I) den derzeit effektivsten Packalgorithmus des Kommandos bzip2. Wurde ein Archiv einmal gepackt, ist bei allen weiteren Operationen die Option für den jeweiligen Packer anzugeben! Das Packen funktioniert allerdings nicht bei Multilevel-Archiven. Ein Ausweg wäre das »vorab«-Komprimieren einer jeden Datei (z.B. mittels eines Skripts) mit anschließender Archivierung. Inkrementelles Backuptar unterstützt nur eine rudimentäre Variante des inkrementellen Backups, in dem Daten zur Archivierung ausgewählt werden können, die »neuer« als ein anzugebendes Datum sind. Das Datum (-n Datum) ist hierbei im Format »Jahr-Monat-Tag« anzugeben. Um z.B. alle Dateien zu erfassen, die in den letzten 7 Tagen (ab aktuellem Zeitpunkt) modifiziert wurden, kann folgender Kommandoaufruf verwendet werden:
Im Beispiel wurde bewusst die etwas verwirrende Kalkulation des Datums mit Hilfe von date gewählt, da dessen Einsatz das Schreiben eines Skripts zum automatischen Erzeugen von inkrementellen Backups vereinfacht. Überprüfung des ArchivesUm sich von einer ordnungsgemäßen Archivierung zu überzeugen, sollte das resultierende Archiv einem Test unterzogen werden. Da der Slash automatisch entfernt wurde, ist zuvor ins Wurzelverzeichnis zu wechseln oder das Arbeitsverzeichnis mit -C Pfad zu ändern und (in Bezug auf obiges Beispiel) Folgendes aufzurufen:
tar überzeugt sich nun, dass alle Dateien des Archivs auch im Dateisystem existieren. Sobald eine Unstimmigkeit festgestellt wird, wird das Kommando den Fehler ausgeben:
RecoveryZu einem Backup gehört natürlich auch eine Möglichkeit, dieses wieder zurückzuspielen. Hier gelangt die Option -x (extract) zum Einsatz. Im Falle von relativen Pfadangaben im Archiv wird die Verzeichnisstruktur unterhalb des aktuellen Verzeichnisses erzeugt. Sie sollten also entweder zuvor ins Zielverzeichnis wechseln, oder dieses mit -C Pfad explizit angeben:
Handelt es sich um ein auf mehrere Medien verteiltes Archiv, muss die Option -M angegeben werden. tar fordert dann zum Medienwechsel auf. Möchten Sie nur einzelne Dateien extrahieren, sind deren Namen mit vollständiger Pfadangabe auf der Kommandozeile anzugeben. Hier hilft eventuell die Option -t, um den korrekten Namen, so wie er im Archiv gespeichert ist, zu erfahren:
Grafische Verpackung: kdatMit dem Programm kdat steht den KDE-Benutzern eine grafische Oberfläche zur Backupverwaltung mit tar zur Verfügung. Leider wird als Backupmedium derzeit nur das Tape unterstützt. Abbildung 1: Backups mit kdat Nach dem Start von kdat sollte unter dem Menüpunkt »BearbeitenEinstellungen« der Typ des Tapes (Speicherkapazität, Device, Blockgröße) angepasst werden. Anschließend muss das Tape gemountet werden, wobei kdat testet, ob das Band formatiert ist und ggf. zu einer Formatierung auffordert (Vorsicht: eventueller Datenverlust). Das vorgeschlagene »Label« kann übernommen werden, es ist ein eindeutiger Name für das Backup. Im Hauptfenster ist der Verzeichnisbaum u.a. des Rechners dargestellt. Jedes zu sicherne Verzeichnis bzw. jede Datei ist durch Klick mit der rechten Maustaste zu selektieren. Ein Verzeichnis schließt dabei die enthaltenen Dateien/Verzeichnisse ein, wobei diese wiederum von einer Sicherung ausgeschlossen werden können. Ein markierter Eintrag ist hervorgehoben dargestellt. Über das Sichern-Symbol (oder »DateiSichern«) werden alle selektierten Dateien und Verzeichnisse auf das Tape geschrieben. Um nicht bei jedem Aufruf die Dateien einzeln markieren zu müssen, können beliebig viele Sicherungsprofile angelegt werden. Jedes Profil enthält eine Liste der zu sichernden Daten.
cpio (cpio in/out) besitzt einen ähnlichen Funktionsumfang wie das zuvor beschriebene Kommando tar, so dass wohl eher die Vorliebe des Benutzers das eine oder andere Werkzeug favorisiert. Ein Vorteil wäre dennoch zu nennen: cpio verzweifelt nicht an beschädigten Archiven und vermag zumindest den unversehrten Teil komplett wieder herzustellen.
cpio kennt drei Betriebsarten:
Volles und inkrementelles BackupUm Dateien in einem cpio-Archiv zu speichern, müssen deren Namen dem Kommando mitgeteilt werden. cpio erwartet allerdings, dass jeder Dateiname auf einer neuen Zeile erscheint. Deshalb füttert man das Kommando am einfachsten über eine Pipe:
Das Beispiel sichert alle auf ".txt" endenden Dateien des aktuellen Verzeichnisses auf die Diskette. Die Ausgabeumleitung ist wichtig, da sonst die Dateiinhalte auf dem Bildschirm landen würden. Hiermit kennen Sie nun das Prinzip des Backups mit cpio; zur Implementierung eines inkrementellen Backups bietet sich die Nutzung der Möglichkeiten des Kommandos find an, mit dem nach den verschiedensten Kriterien nach Dateien gefahndet werden kann. So archiviert der Aufruf von:
alle Dateien aus dem Verzeichnis /etc, wobei alle Unterverzeichnisse, nicht aber die darin befindlichen Unterverzeichnisse berücksichtigt werden. Die Option »-depth« von find bewirkt, dass der Name eines Verzeichnisses selbst erst nach den enthaltenden Daten ausgegeben wird. Bei eventuellem Zurückschreiben der Daten, wird nun der häufige Fehler verhindert, dass ein Verzeichnis mit »falschen« Zugriffsrechten erzeugt wurde und anschließend das Übertragen der Daten in dieses scheitert. Durch die hier gewählte Reihenfolge wird mit der ersten Datei aus dem Verzeichnis dieses mit den korrekten Rechten gesetzt (mit Rechten, die das Schreiben der Datei ermöglichen). Im Sinne eines inkrementellen Backups ist aber sicher die Suche nach Dateien, die innerhalb einer bestimmten Zeitspanne geändert wurden, interessant. Der nächste Aufruf findet alle Dateien des Verzeichnisses /etc, deren Modifikationszeit nicht älter als 5 Tage ist:
Überprüfung des ArchivesUm sich eine Liste der Dateien eines Archives zu betrachten, ruft man das Kommando im »copy in«-Modus auf:
Die Option -t bewirkt die Anzeige des Archivinhalts und verhindert das Entpacken. -v bringt die Rechte der Dateien zum Vorschein und -I Archiv lässt cpio die Daten aus dem Archiv anstatt von der Standardeingabe lesen. Ein Vergleich der Dateien im Archiv mit den Dateien im Verzeichnisbaum ist nicht direkt möglich. Hier kann nur ein Entpacken der Daten in ein separates Verzeichnis mit anschließendem Dateivergleich (z.B. mit diff) helfen. RecoverySchließlich möchte man die Daten auch wieder zurückschreiben können. Hierzu ist cpio im »copy-in«-Modus wie folgt zu starten:
Im Beispiel stellt cpio nur fest, dass die gewünschte Datei nicht älter ist als die im Archiv enthaltene Version. Also tut das Kommando nichts. -d erzwingt das Anlegen von Verzeichnissen, falls diese nicht schon existieren, die nachfolgende Angabe von zu rekonstruierenden Dateien kann entfallen, dann werden alle Dateien aus dem Archiv extrahiert.
tar und cpio enthalten wenige Eigenschaften, die man sich von einem guten Backup-Werkzeug wünscht. Zwar sind beide effektiv zum Erzeugen voller Backups geeignet, jedoch besitzen sie von Haus aus keinerlei Unterstützung inkrementeller Datensicherungsstrategien. Allerdings passen sie mit ihrer Philosophie ideal in das Kommandokonzept von Unix, wo jedes Standardkommando einen »sinnvollen« Funktionsumfang mit sich bringen sollte und alle komplexeren Aufgaben durch Kombination der Grundbausteine realisiert werden. Ein Backup wird auch heute häufig auf Basis von Shellskripten und unter Verwendung der bereits vorgestellten Kommandos implementiert. dump hingegen verdient die Bezeichnung eines Backup-Werkzeuges. Es vermag sowohl mit vollen als auch mit inkrementellen Backups umzugehen, wobei letztere in bis zu 9 Abstufungen vorgenommen werden können. Multilevel-BackupsEin Multilevel-Backup bezeichnet eine Strategie, wobei ein volles Backup mit inkrementellen Backups kombiniert wird. Im einfachsten Fall wird einmal in einem Monat ein volles Backup des Datenbestandes vorgenommen und anschließend werden täglich nur die modifizierten Dateien gesichert. Dem vollen Backup wird hierbei das Level 0 zugeordnet und die weiteren Sicherungen erhalten das Level 1. Nach Ablauf des Monats wiederholt sich der Vorgang. Eine Verallgemeinerung führt nun beliebig viele Level ein, wobei bei einem Backup des Levels x alle geänderten Daten im Zeitraum seit der letzten Sicherung desselben Levels berücksichtigt werden. Der Sinn solcher Level ist die Einsparung von Speichermedien bei gleichzeitiger Verlängerung der Backup-Historie. Möchten Sie bspw. die Daten über den Zeitraum dreier Monate aufbewahren, so benötigen Sie bei Realisierung mittels zweier Level ca. 92 Bänder (1 Band für das volle Backup und für jeden Tag ein weiteres). Ein anderes Vorgehen wäre ein anfängliches volles Backup (Level 0, 1 Band), jeden Monat ein Backup Level 1 (2 Bänder, der 3. Monat wird vom kommenden vollen Backup erfasst), jede Woche ein Backup Level 2 (4 Bänder) und schließlich ein viertes Level zur Speicherung der täglichen Daten (6 Bänder). Mit 13 Bänder können Sie also jederzeit den Datenbestand auf den Stand des letzten Tages bringen. Die Verwendung von dump
dump vermag derzeit nur mit dem Datensystem ext2 zusammen zu arbeiten. Ein zu sicherndes Dateisystem kann in der Datei /etc/fstab markiert werden, so dass bei einem Aufruf von dump über den gesamten Verzeichnisbaum nur diese Dateisysteme berücksichtigt werden. dump versucht in der Voreinstellung das Gerät »/dev/st0« zu öffnen. Existiert das Device nicht, fordert das Kommando zur Eingabe eines anderen Ausgabegerätes auf. Mit der Option -f Datei kann die Sicherung in eine beliebige Datei umgelenkt werden. Dem Kommando ist natürlich mitzuteilen, was zu sichern ist. Hier kann entweder ein Verzeichnis oder das Device angegeben werden. Des Weiteren muss das Backup-Level (0-9) benannt werden. dump selbst ist in der Lage, die Zeiten der letzten Sicherung eines Levels zu notieren und anhand derer zu entscheiden, ob ein erneutes Backup dieses Levels überhaupt notwendig ist. Hierzu schreibt das Kommando, wird es mit der Option -u aufgerufen, die Zeiten in die Datei /etc/dumpdates. Existiert keine Datei, sollte zuvor eine leere von Hand erzeugt werden. Volles BackupUm nun ein volles Backup des Verzeichnisses »/etc/rc.d« auf Diskette zu sichern, ist Folgendes einzugeben:
dump fordert selbständig zum Mediumwechsel auf, wenn dessen Speicherkapazität nicht mehr genügt. dump hat in obigen Beispiel die letzte Sicherung des zugrunde liegenden Dateisystems in der Datei »/etc/dumpdates« vermerkt. Die Informationen sind dort im Klartext enthalten und können somit editiert werden, um z.B. temporär eine andere Backupstrategie zu wählen. Mit der Option -W zeigt dump die gesicherten Dateisysteme mit Datum und letztem Backuplevel an und gibt zusätzlich noch Empfehlungen, welches Dateisystem eine erneute Sicherung vertragen könnte:
Inkrementelles BackupUm nun eine Level-2-Archivierung desselben Dateisystems vorzunehmen, gibt der Administrator folgende Zeile ein:
Die eigentliche Aufgabe beim Backup ist es nun, die verschiedenen Level-Sicherungen in sinnvollen Zeiträumen anzuordnen, z.B.
Es bietet sich an, ein solches Schema per cron-Job automatisch zu realisieren. Die Aufgabe des Administrators reduziert sich damit auf das rechtzeitige Wechseln der Bänder. Überprüfung des Archives mit restoreUm einen Vergleich der im Archiv vorhandenen mit den installierten Dateien vorzunehmen, dient das Kommando restore in Verbindung mit der Option -C. Wird kein weiteres Argument angegeben, versucht restore das Archiv von /dev/st0 zu lesen. Wir verweisen es deshalb auf eine andere Datei (Option -f Datei):
Die angeblich fehlenden Dateien sind auf einen Link im archivierten Verzeichnis zurückzuführen und können ignoriert werden. Recovery mit restoreZum Recovery der Daten wird im einfachsten Fall ein Archiv mittels recover und der Option -r zurückgeschrieben. Beachten Sie, falls Sie alle Daten durch ihre Kopie aus den Archiven ersetzen wollen, alle Archive in der Reihenfolge ihrer Aufzeichnung einzuspielen, d.h. Sie spielen zunächst das volle Backup (Level 0) ein, dann alle Backups des Levels 1 usw.
Eine Besonderheit von recover ist der interaktive Modus (Option -i), der die Selektion einzelner Dateien aus einem Archiv ermöglicht.
Die Kommandos ls, cd und pwd besitzen gleiche Bedeutung wie in der Shell, wobei als Argument für ls nur Dateinamen mit enthaltenen Metazeichen jedoch keine Optionen zulässig sind. Um nun eine Liste der zu extrahierenden Dateien zu erstellen, werden Dateien mit add hinzugefügt und mittels delete entfernt. In der Ausgabe von ls erscheint eine Markierung vor den in der Liste enthaltenen Dateien. Mit extract werden schließlich die markierten Dateien aus dem Archiv ins System eingespielt, wobei recover zunächst zur Eingabe der Volumenummer auffordert (also das Band, auf dem sich die Datei befindet). Ein Beispieldialog könnte wie folgt aussehen:
Von den vorgestellten Backup-Werkzeugen besitzt Taper die freundlichste Benutzerschnittstelle. Es unterstützt die volle Palette an Backupmedien (Tapes, Festplatte, SCSI, Floppy). Wesentlich ist die zusätzliche Speicherung des Inhatlsverzeichnisses eines Archivs, das die Suche vor allem in großen Datenbeständen enorm beschleunigt. Start von TaperDer erste Aufruf erfordert die Angabe des Backup-Mediums. Taper speichert die Angaben, so dass bei folgenden Anwendungen der Kommandoaufruf ohne Argumente genügt:
Nach dem Start befinden wir uns im Hauptmenü. Backup mit TaperAbbildung 2: Taper Startmenü Backup-Module: Zunächst sind der Titel des Backups und des Volumes anzugeben bzw. die vorgeschlagenen Werte eines vorangegangenen Taperlaufes zu bestätigen. Bei einem existierenden Backuparchiv besteht die Wahl, diesem Daten hinzuzuführen oder das bestehende Archiv zu überschreiben. Abbildung 3: Anlegen eines neuen Backuparchivs Das folgende Fenster ist in vier Bereiche aufgeteilt, zwischen denen mit [Tab] gewechselt werden kann. Links oben befindet sich die Verzeichnisansicht. Mit den Cursortasten kann die Selektion verändert werden. Ein [Enter] auf einem Verzeichniseintrag wechselt in dieses. Um einen selektierten Eintrag zum Archiv hinzuzufügen, ist [i] zu drücken. Handelt es sich um ein Verzeichnis, werden alle enthaltenen Dateien/Unterverzeichnisse automatisch zum Archiv hinzugefügt. Um einzelne Dateien/Verzeichnisse vom Archiv zu verbannen, sind diese zu selektieren und [u] einzugeben. Bei indirekt zum Backup markierten Einträgen (die durch Auswahl des übergeordneten Verzeichnisses selektiert wurden) ist zum Ausschluss dieser [e] (anstatt [u]) zu einzugeben. Nähere Informationen zu einer selektierten Datei / einem Verzeichnis erhält man mittels [d]. Abbildung 4: Selektion der zu sichernden Daten Im Fenster rechts oben wird der aktuelle Inhalt des Archivs (Dateien, die zuvor archiviert wurden) angezeigt. Links unten stehen die zum Backup selektierten und rechts unten die vom Backup ausgeschlossenen Dateien. Um solch eine explizit ausgeschlossenen Datei wieder für die Archivierung vorzusehen, ist in das Fenster zu wechseln ([Tab]) und die Datei aus der Auswahl zu entfernen ([u]). Durch Betätigen von [h], [?] oder einer beliebigen, nicht mit einer Funktion versehenen Taste erhält man eine Hilfe zu Taper: Abbildung 5: Kurzhilfe zu Taper Das Erzeugen des Backups wird mit Eingabe von [f] begonnen. Ist die Kapazität eines Backupmediums erschöpft, fordert Taper zum Wechsel dessen auf. Nach Abschluss des Vorgangs erscheint ein Statusbericht auf dem Bildschirm: Abbildung 6: Statusbericht zu einem Backup Alle getroffenen Änderungen können durch Eingabe von [q] verworfen werden. Backup-ModiDer default-Modus von Taper ist ein inkrementelles Backup. D.h. Taper schaut vor dem Archivieren der selektierten Dateien nach, ob diese im verwendeten Archiv bereits existiert. Die dortige Datei wird nur ersetzt, falls sie älteren Datums ist, als der selektierte Eintrag. Ebenso werden Dateien, die 0 Bytes enthalten, ignoriert. Beim vollen Backup hingegen, wird eine Datei prinzipiell ersetzt, unabhängig davon, ob die Version im Archiv ggf. gleichen oder gar neuerem Datums ist oder ob ihr Inhalt leer ist. Das voreingestellte Backup-Verhalten kann entweder per Kommandozeilenoption (inkrementelles Backup mittels --incremental-on (+u); volles Backup mittels --incremental-off (-u)) oder in den Preferences (Change preferences Backup preferences 2) eingestellt werden.
Die Dateien lassen sich ebenso gepackt im Archiv ablegen. Taper kennt hierzu drei Typen von Kompressionen. Typ 1 verwendet das Unix-Kommando gzip (wer Taper aus dem Quellen selbst übersetzt, kann in »defaults.h« auch ein anderes Kompressionsprogramm eintragen). Typ 2 ist ein Taper-eigenes compress-ähnliches Verfahren und Typ 3 ist »gzip« nachempfunden. Die internen Verfahren arbeiten schneller, liefern aber i.A. schlechtere Packraten. Der Typ der Komprimierung kann wiederum in den Preferences eingestellt (Change preferences Backup preferences 1) oder per Kommandozeile (--compress-typ Typnummer bzw. -c Typnummer) mitgegeben werden.
Restore mit TaperIm Hauptmenü ist der Eintrag Restore Module zu wählen. Taper präsentiert eine Liste aller Archive. Das zu rekonstruierende ist zu selektieren und die Wahl mit [Enter] zu bestätigen. Taper fragt nun nach dem Verzeichnis, in das die Daten aus dem Backup eingespielt werden sollen. Ist das Ziel dasselbe Verzeichnis, aus dem die Daten des Backups gewonnen wurden, kann auf die Eingabe verzichtet werden. Das Restore-Fenster des Programmes ist wiederum in 4 Bereiche unterteilt. Links oben sind alle Dateien aus dem Archiv dargestellt. Rechts oben wird das komplette Archiv dargestellt, also einschließlich der vom Backup ausgeschlossenen Daten (in runden Klammern). Links unten stehen alle zur Wiederherstellung vorgesehenen Dateien; das rechte untere Fenster bleibt leer. Abbildung 7: Restore mit Taper Die Auswahl der Dateien erfolgt analog zum Backup-Modul: Mit [i] wählen Sie eine Datei/Verzeichnis aus (ein Verzeichnis schließt wiederum die enthaltenen Dateien/Verzeichnisse ein); ein [u] verwirft einen zuvor selektierten Eintrag. Mit [f] wird die Wiederherstellung begonnen bzw. mittels [q] verworfen.
Was tun, wenn das Dateisystem zerstört ist, ein aktuelles Backup aber nicht zur Verfügung steht? Bevor die Flinte ist Korn geworfen wird, kann ein Reparaturversuch des Dateisystems nicht schaden. Doch Vorsicht! Wir bewegen uns auf einem sehr unsicherem Terrain, eine unbeholfene Aktion und all die Daten sind unwiderruflich pfutsch... Da sollte man sich doch besser zuvor ein Backup vom zerstörten System erstellen, um im Falle eines Falles weitere Versuche unternehmen zu können. Aber welches der Backup-Kommandos ist schon in der Lage, zerstörte Dateien aufzuzeichen? Keines, hier kommt dd zum Einsatz, das einfach ab einem bestimmten Startpunkt eine bestimmte Menge »roher« Daten liest und diese 1:1 in eine Zieldatei oder auf ein Zielgerät überträgt. Diese Eigenschaft erlaubt es auch, Dateien beliebiger Dateisysteme zu sichern, selbst wenn Linux diese gar nicht lesen kann...
QUELLE und ZIEL können hierbei sowohl ein Device als auch eine Datei sein. Werden keine weiteren Optionen angegeben, so werden Daten im Umfang von QUELLE kopiert. Handelt es sich bei QUELLE um eine Partition, wird deren gesamter Inhalt kopiert:
Im Beispiel wird die gesamte erste IDE-Festplatte (/dev/hda) des Systems auf die dritte (/dev/hdc) kopiert. Es sollte jedem bewusst sein, dass der alte Inhalt der dritten Festplatte damit überschrieben wird. Auch sollte diese über die gleiche Kapazität wie die erste Platte verfügen (sonst muss man sich die Anzahl der kopierten Bytes merken). Um die Daten später zurückzuspielen, vertauscht man die Angaben von QUELLE und ZIEL. Ist das Ziel einer Kopieraktion eine Datei, könnte bei Kernel-Versionen <2.4 die Beschränkung der Dateigröße von 2 GB unser Vorhaben zunichte machen, in einem solchen Fall muss die QUELLE auf mehrere Zieldateien aufgeteilt werden. Hierzu benötigt dd mehrere Optionen. Mit bs=BYTES muss die Anzahl Bytes, die in einem Schritt zu lesen oder schreiben sind, angegeben werden. Wieviele Schritte getätigt werden sollen, legt die Option count=ANZAHL fest. Um bspw. den Masterbootsektor (Mbr) der ersten Festplatte in eine Datei zu schreiben, könnte man folgenden Aufruf verwenden:
Um jetzt den Superblock (1 k groß) der ersten Partition zu sichern, müssen sowohl Mbr als auch der 512 Bytes lange Bootsektor (also zwei Blöcke) übersprungen werden. Hierzu verwendet man die Option skip=ANZAHL.
Das Beispiel demonstriert zwei Sachen: Zum einen, wie ein Abbild auf mehrere Dateien verteilt werden kann und zum anderen, dass die Sache verdammt kompliziert ist. Deswegen wird man dd niemals als Werkzeug für ein regelmäßiges Backup einsetzen, sondern nur in außergewöhnlichen Situationen, wie eingangs beschrieben.
AMANDA (Advanced Maryland Automatic Network Disk Archiver) ist ein auf den Kommandos dump bzw. tar basierendes Backup-System, das die Datensicherung in einem Netzwerk unterstützt. Hierzu wird ein Rechner als Backup-Server eingerichtet, der neben verschiedenen Unix-Clients über den Samba-Service auch die Daten eines Windows-Rechner zu verwalten vermag. InstallationDie Aktualität der Programmversionen sollte bei jeder modernen Distribution gewährleistet sein. Als Programme müssen installiert sein: Bei den meisten Distributionen wird man um die Erzeugung der Programme aus den Quelltexten nicht umhin kommen, deshalb soll das Vorgehen hier kurz skizziert werden (im Basisverzeichnis der Quellen finden Sie die Dateien README und INSTALL mit weitergehenden Informationen). Im Quellverzeichnis befindet sich das Skript configure, das die Steuerdateien für den folgenden Kompilierungsvorgang erzeugt. Einige Optionen für configure sind zwingend erforderlich: --with-user=Amanda_Benutzer Amanda läuft unter dieser Benutzerkennung.
--with-group=Amanda_Gruppe Amanda läuft unter dieser Gruppenkennung.
--prefix=Verzeichnis Amanda wird unterhalb dieses Basisverzeichnisses installiert (Voreinstellung ist /usr/local).
Unterhalb des Basisverzeichnisses für die Amandainstallation werden die Server-Programme in ein Verzeichnis »sbin«, die Client-Programme unter »libexec«, die dynamischen Bibliotheken unter »lib« usw. eingespielt. Jeder dieser voreingestellten Pfade lässt sich über eine Option separat modifizieren. Rufen Sie configure --help auf, um eine vollständige Liste der Optionen zu erhalten. Im Zusammenhang mit durch Firewalls geschützten Systemen kann die Konfigurationsoption --portrange=TCP-Port1[,TCP-Port2...] erforderlich werden, um den Datentransfer auf die genannten TCP-Ports zu beschränken. Eine Firewall darf aber niemals den UDP-Port 10080 sperren, der dem Server zu Anfragen an die Clients dient. Der nachfolgende Aufruf sollte für zahlreiche Fälle genügen:
Der Übersetzungsvorgang und die anschließende Installation werden durch zwei make-Aufrufe eingeleitet:
Anmerkung: Die nachfolgende Beschreibung geht von obigen Angaben aus, d.h. für alle nicht genannten configure-Optionen gelten die Default-Einstellungen. Dies gilt insbesondere für den Namen der verwendeten Konfiguration (Voreinstellung »DailySet1«; überschreibbar durch die Option --with-config=...), der serverseitig als Verzeichnisname dient. Der Backup-ServerZunächst sollten Sie die Verzeichnisse anlegen, die der Server nachfolgend für Status- und temporäre Dateien verwendet. Dies sind im Einzelnen
Die Namen der beiden ersten Verzeichnisse korrespondieren mit der Bezeichnung der Konfiguration. »DailySet1« ist die Voreinstellung, falls Sie bei der Kompilierung nichts anderes angegeben haben. Unter /etc landen die Setup-Daten; in /var werden Protokolldateien und Datenbanken abgelegt. /dump/amanda dient als Zwischenlager. Hier sammelt der Server zunächst die zu archivierenden Daten. Erst wenn sie komplett sind, schreibt er sie aufs Band. Informationen zur Aktualität der Archive hält der Server in einer Datei /etc/amandates, die noch erzeugt werden sollte:
Ein Backup macht erst wirklich Sinn, wenn ein solches regelmäßig vorgenommen wird. So ist ein Eintrag in den Terminkalender dringend zu empfehlen:
Da es sich bei Amanda um einen Netzwerkdienst handelt, werden einige Einträge in Konfigurationsdateien notwendig. Tragen Sie die folgenden Zeilen in die /etc/services ein:
Beachten Sie, dass der UDP-Port zwingend 10080 sein muss. Die TCP-Ports können ggf. angepasst werden. amandaidx und amidxtape sind Dienste, die den Zugriff auf die Kataloge und das Backup-Bandlaufwerk ermöglichen. amanda ist der Backup-Client. Da sicher auch auf dem Server eine Datensicherung erwünscht ist, sollte dieser Eintrag nicht fehlen. Damit sie bei Bedarf aktiviert werden, sind Einträge in der Datei /etc/inetd.conf (bei Verwendung von inetd) oder in /etc/xinetd.conf (xinetd) erforderlich:
Der Eintrag der fünften Spalte entspricht dabei dem Namen, der mittels »configure --with-user=...« vereinbart wurde. Auch müssten Sie eventuell die Pfade der Programme (Spalte 6) korrigieren, falls Sie bei der Konfiguration andere Einstellungen vorgenommen haben. Im folgenden Schritt muss die Konfigurationsdatei des Servers angelegt werden. Die den Quellen beiliegende Beispieldatei kann als Ausgangspunkt dienen:
Editieren Sie die Datei DailySet1 und passen folgende Einträge an Ihre Gegebenheiten an: org Berichte, die Amanda per Mail versendet, enthalten diesen Text als "Subject".
mailto Die Empfängeradresse für Berichte.
dumpuser
dump sollte unter derselben Benutzerkennung laufen wie Amanda, deshalb
sollte hier der mit "configure --withuser=..." vereinbarte Name stehen.
dumpcycle
Der Zyklus für ein volles Backup. Die Zeit sollte in Konfigurationen mit
vielen Clients nicht zu gering gewählt werden; zumindest muss das Backup
vollständig auf die Bänder gespielt werden können, bevor ein neuer
Zyklus startet. Allerdings bedingt ein langer Backupzyklus entsprechend viele
Bänder, da mehr Sicherungsdaten aufgehoben werden müssen. Typisch sind
hier Werte zwischen 1 Woche und 3 Monaten.
runspercycle
Die Anzahl Durchläufe pro Zyklus. Wie viele inkrementelle Backups werden
also innerhalb der Zeitspanne eines vollen Backups vorgenommen.
tapecycle
Der Bandzyklus ist die minimale Anzahl Bänder, die Amanda benötigt.
Er errechnet sich aus dem Wert »runspercycle« mal
»runtapes« und sollte niemals kleiner gewählt werden, da Amanda
ansonsten die Bänder des letzten vollen Backups überschreibt. Stellt
man Amanda mehr Bänder zur Verfügung, verfügt man über eine
längere Backup-History (über das letzte volle Backup hinaus), da Amanda
die Bänder zyklisch beschreibt.
runtapes
Anzahl der Bänder, die für einen Durchlauf maximal verwendet werden.
Genügt der Speicherplatz nicht, bricht Amanda mit einem Fehler ab.
tapedev
Das Device, an dem das Bandlaufwerk hängt. Dieses Device sollte dem
Amanda-Benutzer und der Amanda-Gruppe gehören, sowie Schreib- und Leserechte
diesen gewähren.
tapetype Der Bandtyp.
netusage Bandbreite, die Amanda maximal im Netzwerk verwenden darf.
labelstr
Ein regulärer Ausdruck. Alle Bänder, deren
Namen mit dem Ausdruck überein stimmen, gelten als reserviert. Die Bandnamen
lauten DailySet1-xx, wobei »DailySet1« der gewählte Name
der Konfiguration und xx eine Zahl ist.
Der entsprechende Auszug der Konfigurationsdatei könnte so ausschauen:
Nachfolgend sollten Sie ein erstes Band für die Verwendung mit Amanda vorbereiten:
Entsprechend des Eintrags tapecycle in /etc/amanda/DailySet1/amanda.conf müssen Sie obigen Schritt für die weiteren Bänder wiederholen. Erhöhen Sie einzig die Nummerierung »01« fortlaufend. Die Backup-ClientsFür jeden Client, der auf einem vom Server abweichenden Rechner installiert wird, müssen Sie zunächst die Einträge in /etc/services und /etc/inetd.conf vornehmen. Gehen Sie wie beim Server vor mit der Ausnahme, dass in den Dateien einzig die mit »amanda« beginnenden Zeilen aufzunehmen sind. Legen Sie auf den Clients den Benutzer amanda und die Gruppe disk an (bzw. die Namen, die Sie bei der Konfiguration gewählt haben). Der Server muss sich nun ohne Angabe eines Passworts auf dem Client einloggen dürfen. Um dies zu konfigurieren, können Sie entweder im Heimatverzeichnis des Benutzers eine Datei .rhosts (Voreinstellung) oder, falls Sie »configure --amandahosts« wählten, .amandahosts anlegen:
Beide Dateien dürfen nur den Eigentümer zum Lesen und Schreiben berechtigen! Das wär's schon auf Seiten des Clients. Nun muss nur noch auf dem Server eine Datei mit der Beschreibung der zu sichernden Verzeichisse oder Partitionen angelegt werden. Ein Eintrag der Datei disklist besitzt immer folgende Gestalt:
Als Clientname wird der volle Rechnername empfohlen. Verzeichnis kann eben ein solches sein oder aber der Name eines Devices (/dev/hda...). Mit dem Backuptyp soll an dieser Stelle nur auf Standardtypen eingegangen werden. Der Eintrag selbst beschreibt, mit welchen Mitteln das Backup erzeugt werden soll. In der Datei amanda.conf lassen sich eigene Typen deklarieren, die mehrere Standardtypen zusammenfassen (ein Beispiel folgt im Anschluss). Die wichtigsten Typen sind: comprate Wert1 [, Wert2]
Die Kompressionsrate spiegelt die erwartete Verkleinerung des zu sichernden
Verzeichnisses wieder. Wert1 steht für die Kompressionsrate des vollen
Backups und Wert2 für das Inkrementelle. Fehlt Wert2, wird er auf Wert1
gesetzt. Ein Wert von »0.5« besagt, dass die Archivdatei in etwa halb
so groß wird wie das Original.
compress Modus Als Modi sind möglich:
Ohne explizite Modusangabe gilt "client fast". exclude
Die dem Eintrag folgende Liste (mit Wildcards) enthält
Dateien/Verzeichnisse, die vom Backup ausgeschlossen werden. Mit list
<Dateiname> kann ebenso eine Datei angegeben werden, die die
auszuschließenden Dateien und Verzeichnisse enthält.
holdingdisk [yes|no]
Aus Effizienzgründen wird bei realen Konfigurationen nicht unmittelbar
auf das Band geschrieben, sondern die Daten landen in einem temporären
Verzeichnis (die »Holding disk«), um die Clients nicht durch das
langsame Bandlaufwerk auszubremsen. In der Voreinstellung ist die Option
aktiviert (»yes«), mit »no« kann sie abgeschaltet
werden.
index Zum Archiv wird zusätzlich ein Inhaltsverzeichnis erzeugt.
program [DUMP|GNUTAR] Mit welchem Programm soll das Backup vorgenommen werden? Voreinstellung ist DUMP.
record [yes|no] Soll das Backup in der Datei /etc/dumpdates vermerkt werden? Voreinstellung ist ja.
Ein benutzerdefinierter Backuptyp wird in der Datei amanda.conf wie folgt vereinbart:
Eine einfache Datei disklist sieht somit wie folgt aus:
Erster TestEin erster Test soll den korrekten Verlauf der bisherigen Installation beweisen. Als Root wird zunächst der Server begutachtet:
"0 problems found" ist keine schlechte Antwort... Vorläufig stoßen wir ein Backup von Hand an. Später, wenn die Installation perfekt ist, sollte ein Cronjob die Aufgabe erledigen:
Eine Mail sollte dem festgelegten Report-Empfänger bald ins Haus stehen. Mit etwas Glück sieht sie ähnlich der folgenden aus (stark gekürzt):
Der nächste Schritt provoziert einen Fehler, da das Band die Datenmenge nicht aufnehmen kann:
In der Mail äußert sich der Fehler wie folgt (Ausschnitt):
Es genügt nun, ein neues Band für die Nutzung durch Amanda vorzubereiten. Amanda wird später an der Stelle fortfahren, an der das letzte Schreiben wegen des Bandendes stoppte (ein neues Band wurde zuvor eingelegt):
Die nächste uns erreichende Mail sollte wieder einen Erfolg verkünden. Weitere wichtige Kommandos für AmandaFür die tägliche Arbeit bringt das Amanda-Paket eine Reihe von Hilfsprogrammen mit, deren Zweck knapp erläutert sein soll: amcheckdb <Konfiguration>
Konsistenzprüfung der Datenbank auf den Bändern, die in der angegebenen
Amanda-Konfiguration (in obigen Beispielen DailySet1 genannt) aufgelistet
sind
amoverview [-config <Konfiguration>]
Zeigt eine Statistik der von Amanda täglich in Abhängigkeit vom
Backup-Level ("0" entspricht einem vollen Backup) abgearbeiteten Rechner und
Dateisysteme (die voreingestellte Konfiguration ist DailySet1)
amcleanup <Konfiguration>
Generiert einen Mail-Bericht und setzt die Datenbank nach einem Fehler
zurück. Alternativ zum manuellen Aufruf kann das Programm in einem der
Bootskripte aufgerufen werden, um eventuelle Fehler automatisch zurück zu setzen
(trat kein Fehler auf, tut dieses Programm auch nichts)
amverify <Konfiguration><Slot>
Stellt durch Wiedereinlesen des Bandes sicher, dass es durch amrestore
bearbeitet werden kann (nur für GNU tar formatierte Backups)
amtape <Konfiguration> Kommando Benutzer-Schnittstelle für die manuelle Ansteuerung von Bandwechslern unter Amanda
amadmin <Konfiguration> Kommando
Das Kommando für verschiedenste administrative Schritte wie bspw. zum
Ermitteln der notwendigen Bänder zur Wiederherstellung eines Dateisystems oder
das beschleunigte Starten eines vollen Backups für einzelne Platten...
amrmtape <Konfiguration> <Label>
Löscht Bänder aus der Bänderliste und aus der Amanda Datenbank.
(sinnvoll bei einem fehlgeschlagenen Backup oder bei fehlerhaften bzw.
auszutauschenden Bändern)
amstatus <Konfiguration> Gibt den Status eines laufenden Backups bzw. des dazu laufenden"amdump-Prozesses" wieder
Restauration - oder der Fall der FälleFür das Wiederherstellen von Daten mit Amanda gibt es drei prinzipielle Wege. Welcher beschritten werden muss, hängt von den in der Praxis vorkommenden Eventualitäten ab:
Wiederherstellen von Daten mit AmandaZum Wiederherstellen einzelner Dateien, Verzeichnisse oder kompletter Festplatten dient das Kommando amrestore:
Der Einsatz der Optionen wirkt sich dabei hierarchisch von oben aus, d.h. wenn der Plattenname (»diskname«) nicht angegeben wird, werden alle Backups für den vorangestellten Rechner (»hostname«) zurück gespielt. Ist kein Zeitstempel (»datestamp«) gesetzt, werden alles Backups für das zugehörige Rechner-Platten-Paar zurück gespielt. Wurde keiner der Parameter angegeben, finden alle zur Verfügung stehenden Backups bei der Wiederherstellung Verwendung. Während des Zurückholens der Daten vom Band mit amrecover werden diese nicht direkt auf die Datenträger an ihre ursprünglichen Plätze (die sie zum Zeitpunkt des Backups inne hatten) zurück gespielt. Stattdessen werden einzig die Archive vom Band zurück gelesen, welche mittels amflush auf dieses Band geschrieben wurden. Dabei werden Dateien erzeugt, deren Namen folgender Konvention entsprechen:
Eine alternative Realisierung gestattet die Verwendung der Option -p (von "Pipe"), wodurch die Inhalte der Archive unmittelbar an ihre ursprünglichen Positionen entpackt werden. Die Option -c (»compression«) legt die Archivdateien komprimiert auf der Festplatte ab, unabhängig davon, ob sie auf dem Band komprimiert vorliegen oder nicht. Mittels der Option -r (»raw«) interpretiert amrestore die Daten auf dem Band als 1:1-Kopien der gesicherten Daten und schreibt sie unverändert zurück. -h bringt einzig die Header der Archive auf dem Band zum Vorschein. So kann bspw. die Archivierungsmethode ermittelt werden, mit der ein Archiv angelegt wurde. Ein Beispiel: Aus einem unerfindlichen Grund ist uns der Überblick über die Inhalte unserer Backup-Bänder abhanden gekommen. Leider zwingt ein Datenfehler zur Restauration einiger Dateien, doch wo liegen sie? Finden sich in unseren grauen Zellen noch diffusive Ahnungen ob des richtigen Backups, sollten wir das vermutete Band einlegen und amrestore mit möglichst detaillierten Parametern zu Rechnername, Plattenname und Zeitstempel ausstatten. Ist der Schleier der Erinnerung gar zu undurchsichtig, hilft ein Versuch mit bloßer Angabe des Rechnernamens:
Nach einiger Zeit der Suche auf dem Band sollte eine Dateiliste erscheinen:
Welches Format sich hinter den Dateien verbirgt, offenbart ein Aufruf des Kommandos file:
Da es sich im Beispiel um tar-Archive handelt, hilft tar, um in den Archiven nach den zu restaurierenden Dateien zu suchen:
Als Hilfe zum Wiederherstellen von Dateien und Verzeichnissen empfiehlt sich das Kommando amrecover. Dieses Programm bietet eine Benutzerschnittstelle, die auf Indexdaten zugreift, welche für Dumptypen mit eingeschalteter Index-Option beim Backup erstellt wurden (Option index bei define dumptype... aus /etc/amanda.conf). Die Schnittstelle erlaubt eine bequeme Navigation durch die verschiedenen Versionen von gesicherten Dateien und Verzeichnissen. Zu restauriende Einträge lassen sich selektieren und der Vorgang der Wiederherstellung aus dem Programm heraus anstossen. Wiederherstellen von Daten ohne AmandaEin Verlust wichtiger Daten bei gleichzeitiger Zerstörung der Amanda-Installation könnte man als Supergau der Datensicherung betrachten. Was nun? Ein Blick hinter die Kulissen lohnt sich. Unsere Kulissen sind die Bänder mit den Sicherungsarchiven, die hoffentlich unbeschädigt in Griffweite stehen. Amanda hatte die verwendeten Bänder vorab formatiert und genau dieses Format machen wir uns zu Nutze, um an die begehrten Daten zu gelangen. Die erste Datei liegt im Klartext vor (plain text) und ist das so genannte Volume Label. Sie enthält die Volume Serial Number (VSN) und den Zeitstempel der Formatierung durch Amanda. Unmittelbar dem Volume Label folgt eine Liste von Dateien. Bekannt ist nun, dass jede dieser Dateien in Blöcken zu je 32 kByte abgelegt ist, wobei der erste Block (Header) von Amanda gespeicherte Statusinformationen umfasst. Einem Header folgen unmittelbar die Blöcke mit den Daten der Datei. Daran schließt sich der Header der folgenden Datei an, dem wiederum die Datenblöcke folgen. Eine Restauration ohne amrestore läuft somit nach folgendem Schema ab:
Anhand eines Beispiels sollen die einzelnen Schritte begangen werden:
Nach diesem Schema lassen sich fortlaufend die Images vom Band ziehen und ins aktuelle Verzeichnis entpacken. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Korrekturen, Hinweise? |