Equinox
Member
Guten Morgen,
meinen Einstand in diesem Forum muß ich leider mit einem wenig erfreulichen Thema feiern: dem Thema Datenverlust. Man möge mir die etwas langatmige Geschichte verzeihen.
Urplötzlich blieb mein bis dahin jahrelang stabil und problemlos laufendes System (FreeBSD 5, x86) stehen, sagte nach 5 Sekunden was von "cannot free inode, already free" (glaube ich zumindest) und semmelte dann ab. Ein erneuter Anlauf schlug fehl, so nutzte ich die Gelegenheit, ein bereits auf einer zweiten Platte aufgezogenes FreeBSD 7 zur Diagnostik der Platte heranzuziehen. Das ging auch recht gut. Auf verschiedenen Partitionen sind haufenweise Inodes "abgegangen", die entsprechenden lost+found-Strukturen füllten sich. Gut, das war mir im Grunde egal, denn ein System kann man neu installieren, /home aber nicht. Da gab es nämlich folgendes Problem: Die Benutzerverzeichnisse aller Benutzer blieben unbeschädigt, nur mein eigenes (!) kam nicht wieder zum Vorschein. Im Midnight Commander wurde es rot und mit "!" angezeigt, cd war nicht möglich: "cannot open, bad file descriptor". Auch fsck_ffs kam nicht weiter, "bad inode number 306176 to nextinode" lautete die Meldung. Nach kurzer Untersuchung des Quelltextes stellte sich heraus, daß inumber > lastvalidinum vorlag. Und hier war dann auch Schluß mit fsck_ffs. Allerdings bin ich der Ansicht, daß meine Daten allesamt noch vorhanden sind, das ergibt sich aus der Differenz von df -h der Partition und du -sch der noch vorhandenen Daten. Mit fsdb konnte ich mich ein wenig auf der Partition umsehen, und siehe da, es ist noch vieles vorhanden.
Sowas habe ich mit FreeBSD noch nie erlebt, dabei bin ich seit 4.0 dabei und hatte nie (!) was zu mäkeln (bei 7.0 ist es leider das Gegenteil). Das mag auch der Grund sein, warum meine Backups auch zu alt sind. Wenn man jahrelang nix hat, wird man bequem. Naja, dann ist das wohl die Quittung...
Bisher war ich auf dem Trichter, mit clri, fsdb und manch anderen Werkzeugen in der Partition herumzubollwerken, um fsck dazu zu bewegen, nach 306176 weiterzumachen und vielleicht doch noch den lost+found-Vorgang zu vollziehen. Nun aber denke ich, daß es vielleicht besser wäre, fsck_ffs derart zu verändern, daß es diese Problematik übergeht, oder gar selbst ein Programm zu schreiben, was ähnlich fsck_ffs funktioniert.
Die Hoffnung stirbt bekanntnich zuletzt, und mit einem dd-Image, das den Fehler der Partition exakt reproduziert, konnte ich schon etwas experimentieren, allerdings ohne Erfolg. Auch Programme wie ffs2recov, magicrescue, testdisk und The Sleuth Kit (fls, dls, ils) haben mir nicht viel weitergeholfen. Meine Verzweiflung erreichte ein Stadium, in dem ich sogar R-Studio unter wine auf das dd-Image ansetzte. Meine Hoffnung, die Daten seien noch da, wurde hier auch bestätigt. Nur scheue ich mich davor, die Platte zur Wiederherstellung nach Kroll oder so zu schicken - sicher, die kriegen das bestimmt hin, aber zu einem Preis, den ich mir dank meines besch... Gehaltes nicht mal ansatzweise vorstellen kann. Da bleibt nur noch der Weg, es selbst zu versuchen.
Das war jetzt sehr viel Gejammer, und ich danke jedem Lesenden für dessen Geduld. Meine Frage also: Hat jemand mit dieser Thematik Erfahrung und kann Artikel oder dergleichen (auch gern in Englisch) empfehlen, aus denen man über die Gestaltung von UFS lernen kann, in einer Art und Weise, daß es auch halbwegs verständlich wird?
Was mir ursprünglich vorschwebte, wäre eine Rekonstruktion der ursprünglichen Inode-Informationen des Heimatverzeichnisses. Dann dürften alle Folgestrukturen doch wieder zugänglich sein. Mittlerweile denke ich, daß es am sinnvollsten wäre, den lost+found-Weg zu gehen. Sicher, alle Einträge des Heimatverzeichnisses erster Instanz würden ihren Namen verlieren und als #1234567 in lost+found/ landen. Gut, sei's drum, an Dateityp (file-Kommando) und Inhalt bekommt man raus, was es mal war, und wenns ein Verzeichnis war, erkennt man sicher am Inhalt, wie es mal geheißen hat. Aber alles andere sollte - SOLLTE, wenn nicht noch weitere Probleme aufgetaucht sind - wieder vorhanden sein.
Ist das ein tauglicher Ansatz?
Fast traue ich mir nicht, die Frage zu stellen, aber... Hat das schon jemand erlebt? Meinen Recherchen im Internet nach bin ich der zweite (!) auf dieser Welt dem das passiert. Schrecklich! Bekanntlich gibt es ja für die seltensten Krankheiten keine Medizin... :-)
Die en-sprechende Mailingliste von FreeBSD hat mir leider nicht so richtig weiterhelfen können. Natürlich mache ich da niemandem einen Vorwurf draus, das Problem ist ja auch SEHR speziell. In der de-sprachigen Liste traue ich mich kaum zu fragen, und Foren zur Datenrettung behandeln nur den (Schuldigung) Pillepalle-Kram, den unsereiner früher von Hand mit'm Hex-Editor geradegebogen hat und der UNIX-Systeme eh nicht betrifft, ansonsten wollen da natürlich die einschlägigen Firmen dran verdienen.
Über hilfreiche Kommentare würde ich mich sehr freuen und bedanke mich bereits im Voraus dafür. Das solls dann auch erstmal gewesen sein, sonst lasse ich mich noch länger in nörgelnder Weise über FreeBSDs Entwicklung aus, und das wollen wir ja keinem antun. :-)
Mann Mann Mann, das ist mir eine Lehre! Nächstes Geld: BACKUP-Lösung.
meinen Einstand in diesem Forum muß ich leider mit einem wenig erfreulichen Thema feiern: dem Thema Datenverlust. Man möge mir die etwas langatmige Geschichte verzeihen.
Urplötzlich blieb mein bis dahin jahrelang stabil und problemlos laufendes System (FreeBSD 5, x86) stehen, sagte nach 5 Sekunden was von "cannot free inode, already free" (glaube ich zumindest) und semmelte dann ab. Ein erneuter Anlauf schlug fehl, so nutzte ich die Gelegenheit, ein bereits auf einer zweiten Platte aufgezogenes FreeBSD 7 zur Diagnostik der Platte heranzuziehen. Das ging auch recht gut. Auf verschiedenen Partitionen sind haufenweise Inodes "abgegangen", die entsprechenden lost+found-Strukturen füllten sich. Gut, das war mir im Grunde egal, denn ein System kann man neu installieren, /home aber nicht. Da gab es nämlich folgendes Problem: Die Benutzerverzeichnisse aller Benutzer blieben unbeschädigt, nur mein eigenes (!) kam nicht wieder zum Vorschein. Im Midnight Commander wurde es rot und mit "!" angezeigt, cd war nicht möglich: "cannot open, bad file descriptor". Auch fsck_ffs kam nicht weiter, "bad inode number 306176 to nextinode" lautete die Meldung. Nach kurzer Untersuchung des Quelltextes stellte sich heraus, daß inumber > lastvalidinum vorlag. Und hier war dann auch Schluß mit fsck_ffs. Allerdings bin ich der Ansicht, daß meine Daten allesamt noch vorhanden sind, das ergibt sich aus der Differenz von df -h der Partition und du -sch der noch vorhandenen Daten. Mit fsdb konnte ich mich ein wenig auf der Partition umsehen, und siehe da, es ist noch vieles vorhanden.
Sowas habe ich mit FreeBSD noch nie erlebt, dabei bin ich seit 4.0 dabei und hatte nie (!) was zu mäkeln (bei 7.0 ist es leider das Gegenteil). Das mag auch der Grund sein, warum meine Backups auch zu alt sind. Wenn man jahrelang nix hat, wird man bequem. Naja, dann ist das wohl die Quittung...
Bisher war ich auf dem Trichter, mit clri, fsdb und manch anderen Werkzeugen in der Partition herumzubollwerken, um fsck dazu zu bewegen, nach 306176 weiterzumachen und vielleicht doch noch den lost+found-Vorgang zu vollziehen. Nun aber denke ich, daß es vielleicht besser wäre, fsck_ffs derart zu verändern, daß es diese Problematik übergeht, oder gar selbst ein Programm zu schreiben, was ähnlich fsck_ffs funktioniert.
Die Hoffnung stirbt bekanntnich zuletzt, und mit einem dd-Image, das den Fehler der Partition exakt reproduziert, konnte ich schon etwas experimentieren, allerdings ohne Erfolg. Auch Programme wie ffs2recov, magicrescue, testdisk und The Sleuth Kit (fls, dls, ils) haben mir nicht viel weitergeholfen. Meine Verzweiflung erreichte ein Stadium, in dem ich sogar R-Studio unter wine auf das dd-Image ansetzte. Meine Hoffnung, die Daten seien noch da, wurde hier auch bestätigt. Nur scheue ich mich davor, die Platte zur Wiederherstellung nach Kroll oder so zu schicken - sicher, die kriegen das bestimmt hin, aber zu einem Preis, den ich mir dank meines besch... Gehaltes nicht mal ansatzweise vorstellen kann. Da bleibt nur noch der Weg, es selbst zu versuchen.
Das war jetzt sehr viel Gejammer, und ich danke jedem Lesenden für dessen Geduld. Meine Frage also: Hat jemand mit dieser Thematik Erfahrung und kann Artikel oder dergleichen (auch gern in Englisch) empfehlen, aus denen man über die Gestaltung von UFS lernen kann, in einer Art und Weise, daß es auch halbwegs verständlich wird?
Was mir ursprünglich vorschwebte, wäre eine Rekonstruktion der ursprünglichen Inode-Informationen des Heimatverzeichnisses. Dann dürften alle Folgestrukturen doch wieder zugänglich sein. Mittlerweile denke ich, daß es am sinnvollsten wäre, den lost+found-Weg zu gehen. Sicher, alle Einträge des Heimatverzeichnisses erster Instanz würden ihren Namen verlieren und als #1234567 in lost+found/ landen. Gut, sei's drum, an Dateityp (file-Kommando) und Inhalt bekommt man raus, was es mal war, und wenns ein Verzeichnis war, erkennt man sicher am Inhalt, wie es mal geheißen hat. Aber alles andere sollte - SOLLTE, wenn nicht noch weitere Probleme aufgetaucht sind - wieder vorhanden sein.
Ist das ein tauglicher Ansatz?
Fast traue ich mir nicht, die Frage zu stellen, aber... Hat das schon jemand erlebt? Meinen Recherchen im Internet nach bin ich der zweite (!) auf dieser Welt dem das passiert. Schrecklich! Bekanntlich gibt es ja für die seltensten Krankheiten keine Medizin... :-)
Die en-sprechende Mailingliste von FreeBSD hat mir leider nicht so richtig weiterhelfen können. Natürlich mache ich da niemandem einen Vorwurf draus, das Problem ist ja auch SEHR speziell. In der de-sprachigen Liste traue ich mich kaum zu fragen, und Foren zur Datenrettung behandeln nur den (Schuldigung) Pillepalle-Kram, den unsereiner früher von Hand mit'm Hex-Editor geradegebogen hat und der UNIX-Systeme eh nicht betrifft, ansonsten wollen da natürlich die einschlägigen Firmen dran verdienen.
Über hilfreiche Kommentare würde ich mich sehr freuen und bedanke mich bereits im Voraus dafür. Das solls dann auch erstmal gewesen sein, sonst lasse ich mich noch länger in nörgelnder Weise über FreeBSDs Entwicklung aus, und das wollen wir ja keinem antun. :-)
Mann Mann Mann, das ist mir eine Lehre! Nächstes Geld: BACKUP-Lösung.
