Daten-GAU
ArticleCategory:
System Administration
AuthorImage:[Ein Bild von Dir]
![[Photo of the Author]](../../common/images2/DetlefMuller_logo.gif)
TranslationInfo:[Author + translation history. mailto: or
http://homepage
original in de Detlef M�ller
AboutTheAuthor:
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.
Abstract:
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'.
ArticleIllustration:[Das Titelbild des Artikels]
ArticleBody:[The main part of the article]
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.
Bild 2, Partitionierung von sda ( SCSI-Platte )
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
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
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 :)
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 ?
Bild 7, Pass 3 (Ende)
In Pass 3a wird laut der Beschreibung nach verlorenen Dateien / Verzeichnissen gesucht.
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.
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.
