lf340, SystemAdministration: Daten-GAU

LinuxFocus article number 340 http://linuxfocus.org

von Detlef Müller
<detlef_mue/at/web.de>

Über den Autor:

Im Internetcafe nennen sie mich 'Linux', obwohl ich erst seit 2 Jahren mit Tux-OS arbeite. .. Inzwischen könnte es auch noch ein BSD werden ...
Von Beruf 'ohne Job', möchte aber irgendwann in Sachen Linux o.ä. tätig werden. Daher ist Linux für mich sowohl Arbeitsstellenersatz als auch Hobby.
Mein zweites Hobby ist seit Anfang 2004 Attac. Dort möchte ich daran mitwirken, Linux nutzbringend einzusetzen.
Meine erste Baustelle ...
Die Vision : Ein e-democracy-System für Abstimmungen aller Mitglieder per Internet - natürlich mit freier Software.

Daten-GAU

Zusammenfassung:

Eine meiner besten Entschlüsse in Sachen Linux war, nur noch Journaling Dateisysteme zu benutzen. Gestern wurde mir das auf eindrucksvolle Art und Weise bestätigt. Ein fehlerhafter Kopiervorgang ließ alle Daten auf der Partition mit den gesamten Daten eines Linux-Projektes verschwinden und diese unmountbar machen.
So geschehen auf einem ReiserFS Journal Dateisystem ...

Dateisysteme mit Journal sind eines der Goodies, die die Arbeit unter Linux sicher machen. Sie sorgen dafür, daß man doch mal den Reset-Knopf betätigen kann - normalerweise (!) ohne Folgen.
Daß es eben doch üble Folgen haben kann, beschreibt dieser Erlebnisbericht über einen realen Verlust von Daten, und die glückliche Rettung der Bits und Bytes durch ein professionell arbeitetendes Linux-Tool namens 'reiserfsck'.

_________________ _________________ _________________

Linux-Einstieg

Seit ungefähr zwei Jahre ist der Tux auf meinem Rechner; es sind jetzt schon drei Pinguine, die meinen PC bevölkern. Zwei von der Gattung SuSE, einer von der Art Debian, mütterlicherseits Knoppix.

Angefangen hatte es mit SuSE 7.3, für billiges Geld bei EBay ersteigert. Ich hatte schon soviel von Linux gehört, stellte mir vor, selbst einmal als Linux-Spezialist tätig zu werden, also wollte ich jetzt damit anfangen.

Newbie-Probleme ...

Die ersten Schritte waren verdammt nicht einfach. Wie oft habe ich über diese Flut an neuen Fachbegriffen geflucht, und vor allem, daß man sie (meist) nicht erklärt bekommt.
Liest du die ersten Sätze im Handbuch des deutschen Distributors kommt dir eine Flut von KDE, YaST, Bash und Ähnlichem entgegen ... und vorher hatte ein großes Computermagazin von der Distribution mit der besten Dokumenation geschrieben ...
Pustekuchen, nix einfach, verständlich und so.

Ach ja, es geht ja um ... also wieder zur Sache.

ReiserFS auf EISA 486er

Dieses SuSE Linux 7.3 kam auf 'nen alten 486er, noch mit EISA-Bus (.. Tatsache, die Maschinen gibt's auch noch). Der erste harte Reset (Resettaste) und anschließende Neustart des Rechners brachten Probleme. Kein Zugriff mehr auf das Dateisystem, es wurde read-only (nur Lesezugriff) gemountet.
"Was bedeutet das denn nun ?"
Es bedeutete viel Arbeit. Reparaturversuche schlugen fehl ... schließlich installierte ich das ganze SuSE neu.
Das kam so 5 - 6 Mal vor. Und jedes Mal mit dem SuSE Rettungssystem booten, das Reparatur-Werkzeug e2fsck für ext2-Dateisysteme anwenden ; auch mal mit dem elendigen Editor vi die Datei /etc/fstab bearbeiten. Danach war das Dateisystem dann OK, ... oder auch nicht. Im letzten Fall wurde Linux neu installiert. Dann war aber auch schon ein ganzer Tag futsch. Als Newbie dauern solche Aktionen eben länger .....

Bis ich dann auf die Idee kam - angestiftet durch einen Artikel in c't - ein Journaling Dateisystem von YaST installieren zu lassen. Gemacht getan, und seit dem bin ich von Rettungssystem starten usw. verschont geblieben.
Ein sachliches 'replayed nnn transactions in ...' während des Starts von Linux, wenn vorher der PC nicht sauber heruntergefahren worden war, und der Rechner wurde einsatzbereit gebootet.
"Haleluja", denk ich. So ist's schon besser. Ab jetzt kein ext2 mehr, jetzt wird alles mit Journaling gemacht !

'Journal Replay' einer ReiserFS-Partition während des Systemstarts .. (aus LOG-Datei) :



.....
reiserfs: found format "3.6" with standard journal
reiserfs: checking transaction log (sd(8,4)) for (sd(8,4))
reiserfs: replayed 109 transactions in 10 seconds
reiserfs: using ordered data mode
.....

Härtetests

Aber, ich wollte es genau wissen.
Nachdem ich einigermaßen mit den JFs umgehen konnte, wurden Härte-Test durchgeführt; einen harten Reset bei voll aufgerüsteter Oberfläche muß das Dateisystem überstehen.

KDE gestartet, dazu reichlich Programme, Dateien mit dem Editor geöffnet, und dann Reset per Taste. Die Versuche waren erfolgreich. Das Filesystem übersteht das wirklich.

Selbst 'Notaus' während eines laufenden Kopiervorgangs sind kein Problem. Das SCSI-System des 486ers machte ein paar Mal Probleme, aber ReiserFS hielt, was es verspricht. Es versetzte das Dateisystem immer in einen konsistenten, also benutzbaren Zustand. Die geöffneten Dateien hatten ihren alten Stand wieder.
Auch spätere Tests mit den gleichen Erschwernissen unter ext3, der Journal-Variante von ext2, verliefen erfolgreich.

So sieht das laut LOG-Datei bei einer ext3 während des Systembootens aus :



.....
Journalled Block Device driver loaded
(recovery.c, 256): journal_recover: JBD: recovery, exit status 0,
recovered transactions 450798 to 451415
(recovery.c, 258): journal_recover: JBD: Replayed 3756 and revoked 6/15 blocks
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,1), internal journal
ext3_orphan_cleanup: deleting unreferenced inode 355953
ext3_orphan_cleanup: deleting unreferenced inode 355952
EXT3-fs: sd(8,1): 2 orphan inodes deleted
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
.....

Andere Journal FS

Das war die Vorgeschichte ...
In der Zwischenzeit habe ich auch ext3 und XFS im Einsatz gehabt.
Von JFS habe ich die Finger gelassen. Es sollte noch nicht ganz datensicher sein. Bis heute habe ich es noch nicht verwendet. Soll nichts Negatives darüber sagen ... ich hab's halt noch nicht probiert.

XFS ist wieder verschwunden; OK war es auch, ich hatte keine Probleme, habe allerdings auch nicht lange damit gearbeitet.
Das Dateisystem ext3 ist mir geblieben; der 486er läuft jetzt damit und ein Debian / unstable.
Bei ext2 kann man sogar eine existierende Partition mit Daten in ext3 ändern; .. und das sogar im laufenden Betrieb. Hab's probiert, es funktioniert !
Bei der letzten Installation von Knoppix Version 3.4 auf der Festplatte kam wieder mal ext3 zum Einsatz.

Aktuell sind die meisten Dateisysteme auf meinem Arbeits-PC - nur ein PIII/500 - vom Typ ReiserFS.

Die Einteilung der beiden Platten meines Arbeits-PCs.

QtParted hda

Bild 2, Partitionierung von sda ( SCSI-Platte )

QtParted hda

Bild 3, Partitionierung von hda

D-Day

Seit einem 3/4 Jahr arbeite ich an einer Dokumentations-CD für Linux. Dabei fallen große Datenmengen an, Howtos, Tutorials, FAQs, und dann jeweils verschiedene Formate, Archive, und bei Updates die gleiche Menge nochmal. Ich selber schreibe HTML-Dateien hinzu, damit man Überblick über die CD-ROM bekommt.
In den letzten Wochen gibt's viel zu tun daran. Es soll bald eine freie Version dieser CD erscheinen. Also, Image zusammenstellen, ein paar Brenn-Skripte für die Kommandozeile geschrieben - geht einfach schneller, als mit einem KDE-Programm.
Und alles rauf auf meine Festplatte. Mein Datenlager ist dabei /dev/hda5 auf einer 60 GByte IDE-Platte. Die Partition ist knapp 20 GB, schon zu über 80 % belegt. Alles wichtige Bits und Bytes, steckt viel Arbeit drin. Wenn die mal futsch sind, ... äh, kann eigentlich nicht viel passieren, ist ja nicht Windows mit FATxx.

An Backup habe ich auch schon öfter gedacht, nur bisher nie eines gemacht. Ein paar Kopien auf eine andere Festplatte, und das war's auch schon.

Gestern abend komme ich so aus dem Internetcafe, hatte dort Pakete von der SuSE-Webseite heruntergeladen. Es sollen alle Original SuSE-Dokumentationen von 7.3 bis 9.0 auf die CD 2. Zuhause angekommen boote ich den PC mit SuSE 8.1; meistens nehme ich das Debian, aber da die Pakete SuSE-RPMs sind, fahre ich das 8.1 hoch. Das Installieren des ersten Doc-Paketes von 9.0 ging dann auch. Ist also kein Problem, ein neueres Paket auf einer 8er Version. Es werden also die RPMs von 9.0 installiert, auf besagte Partition hda5 kopiert und die RPMs wieder deinstalliert. Das gleiche dann mit 8.0 .

Ohne KDE herunterzufahren, wechsele ich auf eine andere Konsole und gebe ein <STRG ALT> <ENTF> zum Shutdown (Herunterfahren) ein. Es erscheint eine Fehlermeldung auf der Kommandozeile, irgendwas, hab's vergessen; nur .. der PC will nicht mehr. Nichts zu machen ...
Nun, also auf die harte ... Reset-Taste gedrückt, davor schrecke ich inzwischen unter Linux kein bischen mehr zurück.

Der größte anzunehmende Unfall

Beim Hochfahren von Debian erst auch keine Auffälligkeiten, und dann auf KDE-Ebene :
Auf meiner Arbeitspartition werden keine Verzeichnisse angezeigt.
Die ist doch randvoll ... ?
Wahrscheinlich ist die nicht gemountet worden (Quatsch, wird doch beim Start automatisch gemacht).

Und dann, nach einem 'mount /dev/hda5' ... Fehlermeldung im feinsten Englisch .. zuviele Dateisysteme, .. oder falscher Superblock. Da dämmert's langsam.

Was ich da erlebe, ist ein echter Daten-GAU.
Und nu ? ... öhhh. Vielleicht noch ein Mount-Versuch; Blödsinn zwar, einmal nicht gemountet, weshalb soll es denn beim zweiten Mal gehen.
Aber man versucht's dann ja doch. ... Nichts zu machen ! Die Partition mit dem Ergebnis von monatelanger Recherche, vielen selbstgeschriebenen HTML-Seiten, Skripten zum CD-Brennen, gesammelte DEBs und RPMs aus dem Internet, und einiges andere, sind verschwunden, weg, im Nirwana oder sonst wo.
Natürlich sind Daten davon noch auf der Platte, aber werde ich wieder daraufzugreifen können ?

Erstmal zurücklehnen, eine Zigarette kurbeln ...
Als Bastlernatur kommt einem natürlich Datenrettung in den Sinn. Die Partition ist eine ReiserFS. Dafür gibt es doch Tools. Davon hatte ich mal was in einem Artikel über c't-Knoppix gelesen; das Debian ist ursprünglich als Knoppix installiert worden. Demnach müßten die Tools auch da sein.
Und sie sind da.

reiserfsck im Katastropheneinsatz

Also erstmal nachsehen, wo sich das Doc-Verzeichnis von denen befindet, wohl unter /usr/share/doc/reiser-irgendwas. In dem Irgendwas (... soll heißen reiserfsprogs) sind ein paar englische Dateien, für jedes Tool eine, aus den Manpages konvertiert.
Die Musterung der Operationswerkzeuge zur Datenrettung ergibt, daß reiserfsck wohl das 'Skalpell' sein muß. Also, auf geht's ...

Erstmal kurz aufrufen, ohne was zu ändern. Ein -check scheint zu Anfang das Richtige zu sein; erst Diagnose, dann die Operation. .....

# reiserfsck -check

Konsole Bild 1

Bild 4, reiserfsck -check

Ganz verstanden habe ich nicht, aber soviel, reiserfsck hat Fehler gefunden und behauptet, es könnte die beheben. Hört sich ja gut an.

Kurz überlegt und dann geht's ran ans Operieren. Das Skalpell aufgerufen mit ...

# reiserfsck --rebuild tree /dev/hda5

Konsole Bild 2

Bild 5, reiserfsck --rebuild-tree

Der Aufruf bereitet Nervosität. Kein Wunder, jetzt entscheidet sich, was es in den nächsten Wochen so alles zu tun gibt.
"Soll das Dateisystem jetzt wiederhergestellt werden ... ?" .. Ja, es soll.
Man sieht das bekannte 'replaying journal' - das Journal wird eingespielt. Das ist der Wohltäter, der ein Wiederherstellen erst möglich macht; eine Art Inhaltsverzeichnis für alle Teilbereiche der Partition. Zwei Zeilen später wird reiserfsck auf ein unpassendes Null-Bit aufmerksam, und ... korrigiert es.

Es folgt Pass 0 der Wiederherstellung, optisch getrennt auf der Konsole dargestellt. Der Vorgang dauert ca. 15 min. bei den 20 GB; ... zur Kontrolle für den Anwender mit Prozentanzeige.

Auf Bild 2 kann man schon Details über einen Fehler sehen. Was es genau bedeutet ? Hmm, ... frag mich mal einer was Besseres :)

Konsole Bild 3

Bild 6, Pass 0 bis 2, 3 (nur Anfang)

Weiter geht's, ... Pass 1 geht recht schnell. Keine Meldungen über Datenprobleme.

Bei Pass 2 sieht es ähnlich aus.

In Pass 3 hagelt es reichlich Meldungen über Datenfehler. Man erkennt die Dateien, die aus dem Kopiervorgang der SuSE Dokumentationen stammen. Das ist die Bestätigung, daß konkret bei diesem Kopieren etwas schief gegangen ist. War das der Konqueror von KDE 3 oder ist das ein Bug in ReiserFS ?

Konsole Bild 4

Bild 7, Pass 3 (Ende)

In Pass 3a wird laut der Beschreibung nach verlorenen Dateien / Verzeichnissen gesucht.

Konsole Bild 5

Bild 8, Pass 3a

Das Werkzeug wird des öfteren fündig, gibt den Fehler an und korrigiert die entsprechenden Einträge, kommentiert mit einem 'corrected to ...' am Ende der Zeile.
Danach eine Zusammenfassung seines Katastropheneinsatzes, und in Pass 4 die einfache Meldung, daß das Synchronisieren (.. des Journals mit dem Ist-Zustand auf der Festplatte) beendet ist.

Konsole Bild 6

Bild 9, Pass 4 und Ende

Jetzt sollten meine Daten wieder da sein.
Der Mountversuch bleibt ohne Meldung; unter UNIX ein sicheres Zeichen für erfolgreiches Abarbeiten eines Kommandos. :-))

Ende gut - alles gut ?

Und der Konqueror zeigt mir gut bekannte Verzeichnisnamen auf der Partition hda5. Alles wieder da ... wirklich alles ? Von den kopierten Daten fehlt einiges; klar, das war zu erwarten. Ein fehlerhafter Prozeß führt nicht zu einem richtigen Ergebnis. Kann alles wieder rüberkopiert werden.

Den gesamten Datenbestand von hda5 habe ich auch heute, am Tag danach, noch nicht kontrolliert. Es ist aber sehr wahrscheinlich, daß alles vollständig wiederhergestellt ist. Das Tool machte einen wirklich professionellen Eindruck bei der Arbeit !

Wir haben jetzt 16.30 am D-Day+1. Der Katastrophenalarm ist gerade mal 18 Stunden her. Der Bericht dazu (dieser hier) ist schon nahezu fertiggeschrieben; sooo erfolgreich war der Rettungseinsatz.
Gut, daß ich gestern den Verlauf der 'konsole' nach der Wiederherstellung in eine Datei gesichert habe. So habe ich die 'Unfall-Fotos' per Screenshots in diesem Artikel vom Original-Geschehen machen können.

P.S. (2 Tage später) : Kein Anzeichen eines Datenverlustes. Ich arbeite ständig auf der betroffenen Partition.

Fazit

Auch mit einem Journal Dateisystemen können Datenverluste auftreten, nur sind die Chancen des Wiederherstellens groß. JFe sind zuverlässig - und pflegeleicht für den Anwender.
Ein Journal Dateisystem ist für jeden Linux-User ein muß (... man verzeihe mir diese strikte Meinung in der freien Software-Welt).

Die meisten Distributoren dürften inzwischen ein Journal Dateisystem dem Benutzer als Voreinstellung während der Installationsprozedur anbieten.

Und .. damit können auch Backup-Faule Glück haben, und ohne Datensicherung durchs Leben kommen.
Aber, dies soll kein Votum für Unterlassen von regelmäßigen Backups sein.
Also, immer fleißig Backups machen.

Referenzen

Journal Dateisysteme - Artikel :

Journaling Dateisystem für Linux - Linux Gazette Ausgabe 68 vom Juli 2001 ( de | en); .. mit vielen Details.

Abenteuer ReiserFS - Linux Netmag 4/2000 ( de | en)

Doppelte Buchführung - Linux-Magazin 1/2002 (de), Journal Dateisysteme im Vergleich.

Darf es etwas mehr sein ? - Linux-Magazin 6/2000 (de), eine ReiserFS auf LVM vergrößern.

Buchführung für die Festplatte - Linux-Magazin 4/2000 (de), ein Vergleich der 4 Journal Dateisysteme.

Crashfest - Linux-Magazin 7/2001 (de) zu XFS auf SuSE 7.1.

Journal Dateisysteme - Webseiten :

ReiserFS - Die Homepage für ReiserFS.

ext2 / ext3 - Eine andere Angabe ist diese Webseite

XFS - Das Journal Dateisystem von SGI.

JFS - ... ist ein Open Source Projekt von IBM.

Backup - Artikel :

RSync : Das beste Backupsystem - LinuxFocus März/2004.

storeBackup, das unkonventionelle Backup Tool - LinuxFocus Januar/2004.

Arkeia, eine kommerzielle, professionelle Backuplösung für Netzwerke - LinuxFocus Mai/2000.

Autoren und Übersetzer:

de --> -- : Detlef Müller <detlef_mue/at/web.de>

2005-01-14, generated by lfparser_pdf version 2.51