• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Tar-Archiv Wiederherstellen

gundi

Member
Hallo Linux-Club Mitglieder,
meine Notebook-Festplatte hatte Anzeichen auf einen Vorzeitigen Tod gemacht, was mich dazu veranlasst hat eine komplette Datensicherung auf einer externen Platte zu machen. Hierfür hat sich auch die Tar-Archivierung optimal angeboten, sodass ich das System und meine Daten separat als Tar-Archive auf einer externen Platte abgelegt habe.
Nun wollte ich die Daten zurück auf die Notebook-Festplatte spielen, habe aber folgenden Tipp-Fehler gemacht:
Statt das Archiv mit folgenden Befehl zu entpacken:
Code:
tar -xvf Datensicherung.tar /home/user/tmp/.
habe ich ein leeres Archiv erstellt :( :oops:
Code:
tar -cvf Datensicherung.tar /home/user/tmp/.
und mein Archiv durch "." überschrieben. In dem Ordner "/home/user/tmp/." war nichts drinn, also kann eigentlich nur die Referenz zu den Daten geändert worden sein.
Meine Frage: Wie bekomme ich nun die Daten des Tar-Archivs oder zumindest die Referenz zu den Daten widerhergestellt (Es handelt sich um sehr wichtige schulische Daten)? Ich bedanke mich schon jetzt für jede Hilfe.
 
A

Anonymous

Gast
Ganz, ganz dumme Geschichte. Die Datenblöcke sind zwar noch im System vorhanden, aber als frei gekennzeichnet, das heißt wenn du das Filesystem mit dem ehemaligem Archiv nicht schreibgeschützt eingehängt hast und weiterarbeitest, werden über kurz oder lang die einzelnen Blöcke überschrieben. Also als erstes dafür sorgen, dass auf das Filesystem nicht mehr geschrieben werden kann.

Das einzig positive, das ich im Moment sehe, das Archiv war nicht komprimiert, wenn doch, dann ist hier wahrscheinlich schon Schluss.
Alles andere ist Handarbeit und wahrscheinlich jede Menge. Der Aufwand richtet sich uA nach der Größe der Partition, dem Filesystemtype, der Archivgröße und Anzahl der im Archiv enthaltenen Dateien. Auch was sind das für Dateien (Typen?) in etwa wieviele und brauchst du alle dringend wieder oder wirklich dringend nur einige wenige.

Dadurch das die Orginalfile nicht einfach nur gelöchst ist, sondern überschrieben wurde, ist eventuell der Großteil der Reverenzen zu den Datenblöcken aufgelöst oder als solcher nicht mehr so einfach auffindbar (Filesystem abhängig). Also je Größer die Datei und je voller das Filesystem je größer die Chance das sie nicht hinter einander sondern fragmentiert auf der Platte stehen. Also wie ich es sehe. Eventuell geht was mit einem Undelete-Tool zumindestens ist es ein Versuch wert damit noch größere zusammenhängde Fragmente zu finden. Wenn das nichts wird bleibt wahrscheinlich nur alle Datenblöcke nach Tar-Inhalten zu durchsuchen und wenn möglich oder notwendig, richtig zu sortieren (ob das per Hand geht, kommt darauf an was tar für Dateitypen gesichert hat, geht also auch nur mit wenigen Dateitypen problemlos), um an die Dateien zu kommen. Tar macht weiter nichts, wie die einzelnen Dateien die es in ein Archiv packt mit einem Tar-Header zu versehen und aneinander zu kleben und so als eine einzige Datei abzulegen. Wenn man in den Rohdaten zusammenhängede Stücke des Tararchives findet, kann man die darin enthaltenen Dateien mit tar auspacken oder auch per Hand rauskopieren. Man muss nur erst mal (das geht wahrscheinlich mit einem Script) nach den Tarsignaturen suchen. Ist alles allerdings wunderschöne langwierige Fummelarbeit.

Was du brauchst ist wahrscheinlich viel Plattenplatz. Zumindestens ein komplettes Backup der Partition solltest du dir vorher anlegen, bevor du irgend etwas reparieren oder ändern willst. Dann brauchtest du noch einmal mindestend die Größe des ehemaligen Archives, damit du die Blöcke oder das Archiv aus dem Filesystem extrahieren kannst.

Gib erst mal ein paar von den Informationen welche ich oben angesprochen habe, und wie du dich selbst einschätzt, welche Kenntnisse und Erfahrungen du mit und auf der Konsole hast.


robi
 
OP
G

gundi

Member
Hallo robi,
1. gute Nachricht: Ich habe seit dem Überschreiben nicht mehr mit der externen Festplatte gearbeitet (bewusst, da ich weiß, dass ich mir sonst die als unreferenzierten Blöcke auf meiner Festplatte existierenden Daten, überschreiben könnte).
2. schlechte Nachricht: ich hatte meine Daten BZ2 komprimiert, damit möglichst wenig Festplattenspeicher genutzt wird. :oops:
3. Die Festplatte ist 120GB groß und hat einen SATA-Anschluss (aber dass ist ja irrelevant, da ich jeden anderen Anschluss über Adapter erhalten kann). Ich verwende zwei Partitionen, aber nur eine ist betroffen (60GB). Auf dieser war auch nur dieses eine Tar-Archiv und sonst noch nie etwas Anderes. Das Archiv hat 10GB Speichergröße gemessen. Die darin Enthaltenen Dateien werden sich zwischen 300.000 - 500.000 Dateien und Ordner bewegen. Bei den Dateitypen kann man sagen, dass da nahezu alles dabei war (.ODT, .ODS, .TXT, .JPG, .PNG, .BLEND, .XCF, .MPEG, .AVI, .EXE, .FLV, .XAR . . . und viele weitere, die mir jetzt auf die Schnelle nicht einfallen). Die wichtigsten Daten waren eigentlich die OpenOffice-Dokumente, sowie meine E-Mails unter Thunderbird, und viele selbst gestaltete Bilder unter Xara und GIMP.
4. Mein Dateisystem ist EXT3.
5. Ich brauche möglichst viele der Daten, da ich keine weitere Absicherung habe (außer Eine auf DVD, die jetzt schon 3 Jahre alt ist :cry: ).
6. Ich bin zwar ein Advanced-User und kenne auch die meisten Konsolen-Commandos, doch weiß ich nicht, wie man direkt an die Daten der Festplatte kommen kann. :shock:

Dankte für die Hilfe. :D
 
A

Anonymous

Gast
Sieht alles sehr gut aus, und wenn du nicht komprimiert hättest dann hättest du auch innerhalb weniger Stunden wahrscheinlich weit über 95% deiner Daten wieder. Aber komprimiert :?: :mrgreen: :wtf:

Suche erst einmal eine 2. USB-Platte mit mindestens 60GB. Darauf dann mit folgendem Befehl eine Kopie der betroffenen Partition anlegen, und immer nur mit der Kopie arbeiten nie mit dem Orginal, dann kannst du dir immer wieder eine neue Kopie zum testen anlegen, wenn irgend ein Howto nicht funktioniert hat. Vorher dafür sorgen, das wenn du die orginal Platte ins System nimmst, sie gar nicht oder nur ro gemountet wird.

(Eventuell immer mal unter /dev/disk/by-id vorbeischauen, damit du wirklich auch immer die richtige Platte ansprichst.)
angenommen die betroffene Partition ist /dev/sdb1 und die 2 Platte die du als Kopie dazu nimmst wird bei dir /dev/sdc
auf sdc legst du eine Partition an die vorsichtshalber etwas großer als 60GB ist also zB 65GB also /dev/sdc1
mit folgendem Befehl dann eine Kopie der Partition anlegen.
Code:
dd if=/dev/sdb1 of=/dev/sdc1 bs=2048
Vorsicht hier nie if= und of= Verwechseln. siehe dazu eventuell auch vorher http://wiki.linux-club.de/opensuse/Dd wenn dir dieser Befehl nicht geläufig ist.
Jetzt kannst du die Partition auf der kopierten Platte genau so verwenden wie das Orginal, das Orginal kommt jetzt vorläufig unter Verschluss in den Safe.

Ich habe mal ein paar Tests gemacht, eventuell hast du Glück. Bei meinen Tests wurden die Daten des ersten Blocks beim abgeben des von dir angegebenen Kommando nicht zerstört :D . Das Problem ist, wenn das Archiv komprimiert ist hat, man hinter dem Auftreten des ersten Fehlers (braucht nur ein Bit-Kipper zu sein) durch die Komprimierung kaum noch Chancen an richtige Daten zu kommen, wenn der Fehler gleich am Anfang und dort massiv (zB 1024Byte lang oder erster Block total defekt) auftritt :?: Ende

Ich muss erst mal ein paar Tests machen, und das selbst versuchen nachzustellen. Ob und wie man da wieder an die Daten kommt. Eventuell kannst du dich schon mal nach einem Spezi in deinem Bekanntenumfeld umschauen der sich zB. mit debugfs auskennt.

Wenn alle Stricke reisen, bleiben nur die Profis, und das wird teuer. zB http://www.data-recover.de/

@Alle_die_mitlesen
Tip: für solche wichtigen Sicherungsarchive auf externen Festplatten ext2 (nicht ext3) keine Komprimierung und http://wiki.linux-club.de/opensuse/Zugriffsrechte#Erweiterte_Dateiattribute_im_ext2-Dateisystem

robi
 
A

Anonymous

Gast
nicht aufgeben :D :D :D :D

meine Tests haben gezeigt, dass die Blöcke wahrscheinlich alle noch da sind. Aber bei so langen Files doch hochkompliziert auf dem Dateisystem verstreut sind. Ich habe ein Testfilesystem (1GB) erzeugt und darin ein bz2-komprimiertes Tararchiv von /opt (ca 450MB) erzeugt und es nach "deiner Methode" zerstört.

Nach dem letzten Test den ich eben gemacht habe, habe ich innerhalb weniger Minuten das Filesystem auf den alten Stand bringen können und das ganze Archiv 100%tig problemlos wieder herstellen können. Muss noch mal alles richtig zusammenschreiben was ich da gemacht habe, eine Logfile mit den relevanten Befehlen und Ausgaben habe ich mir ja gemacht. Heute aber nicht mehr, ist schon spät. Melde mich wieder

robi
 
A

Anonymous

Gast
Hier jetzt meine Lösung, ich schreibe es etwas ausführlich damit du auch einen Plan davon bekommst, was du da jeweils machst, und außerdem haben dann andere bei ähnlichen Problemen einen guten Anhaltspunkt.

* Was ist beim Überschreiben passiert ?
Dazu musst du einen Begriff kennen Inode . Dort stehen alle Informationen, außer dem Namen, einer File drin. Und dort gibt es auch die Verweise auf die Datenblöcke die zur Datei gehören. Es gibt 15 solcher Datenblockadressen und diese wurden beim Überscheiben auf Null gesetzt, und statt dessen bei dir der erste auf einen neuen Block gesetzt. Zusätzlich wurde noch die Dateigröße geändert. Die Inode deines Archives wurde also nicht gelöscht sondern geändert. An den Inhalten der Datenblöcken und den indirekten Datenverweisblöcken wurde nichts geändert, allerdings sind sie im Filesystem jetzt auch als wieder benutzbar bekannt.

* Was ist zu tun ?
Die Inode der Datei muss erst einmal ermittelt werden. Dazu gehen in diesem Fall viele Befehle. ls -i oder stat aber auch Befehle die hier weiter unten kommen, könnten benutzt werden. Diese Inode kannst du dir schon mal raussuchen. Den Inhalt dieser Inode müssen wir editieren, und zwar müssen wir die 15 Datenblockadressen und die Dateigröße wieder auf den alten Stand bringen. Alle anderen notwendigen Änderungen in der Inode und im Filesystem würde dann ein fsck für uns erledigen, damit das Filesystem wieder sauber ist.

* Woher kommen die Daten die wir brauchen ?
Es handelt sich um ein ext3 Filesystem diese hat ein Journal (siehe zB hier) . In diesem Journal werden Änderungen am Filesystem vermerkt bevor sie am Filesystem ausgeführt werden.
Du schreibst, dass sich in dem betreffendem Filesystem außer an dieser Datei sonst nicht allzuviel geändert hat, also liegt es nahe, dass sich derzeit noch im Journal Änderungsdaten für diese File befinden, ua. auch die letzten für uns relevanten Datenblockadressen und die Filegröße die wir benötigen. Sie sollten dort in den Journal-Kopien der betroffenen Inode zu finden sein.

* Wie können wir die Daten aus dem Journal auslesen ?
Dazu benötigen wir ein kleines Programm ext3grep, dass es allerdings derzeit wohl nicht als fertiges Paket gibt.(habs jedenfalls nicht gefunden)
(Wir haben hier einige Packer im Haus :wink: ich finde es jedenfalls genial )
Also mußt du das Programm selbst compilieren. Wir laden uns die ext3grep-0.7.0.tar.gz herunter und entpacken sie mit tar -xf ext3grep-0.7.0.tar.gz und wechslen in das Verzeichnis ./ext3grep-0.7.0 Zusätzlich werden folgende Pakete auf deinem System benötigt. libext2fs-devel und die Pakete die man für alle Compilierarbeiten benötigt make binutils gcc und davon abhängige, sowie zusätzlich noch den C++ Compiler also gcc-c++
Das ganze geht recht einfach:
./configure
make
make install
(als root)
Kleiner Tip am Rande CheckInstall macht das Leben leichter.
Das tool ext3grep ist ein spezielles Konsolen-Tool für dessen Benutzung man einiges an Grundwissen über ext3 Filesysteme mitbringen sollte. Keine Angst, uns reicht aber für diesen Fall hier ein Befehl völlig aus.

* Das Auslesen der Journaldaten der betroffenen Inode
Also wir haben die KOPIE nicht das Orginal vor uns, davon benötigen wird das Device ich bleibe hier im Beispiel bei /dev/sdc1. Die Inode der betroffenen Archivdatei haben wir schon ermittelt und aufgeschrieben, ich benutze hier im folgenden die Inode 5121. Das Filesystem ist derzeit nicht gemountet. (eingelogt sind wir als root) bitte aber die eigenen Device und Inode Daten in allen folgenden Befehlen verwenden.
Code:
ext3grep /dev/sdc1 --show-journal-inodes 5121
wenn jetzt hier eine Liste durchrauscht hast du fast schon gewonnen. Bei deinen 60GB und der wenigen Verwendung des Filesystems würde ich eine sehr lange Liste erwarten, wir leiten sie desshalb in eine Datei um.
Code:
ext3grep /dev/sdc1 --show-journal-inodes 5121 > /tmp/inode-5121.dump

* Das heraussuchen der richtigen Inode-Kopie
Dazu schauen wir und die eben erzeugte Datei näher an. Hier mal ein Beipiel zur Verdeutlichung was da drinn steht. In diesem Beispiel ist es die Inode Änderung die mir mein Archiv überschrieben hat, und die vorherige Inode, die es wieder herzustellen gilt.
Code:
--------------Inode 5121-----------------------
Generation Id: 250453397
uid / gid: 0 / 0
mode: rrw-r--r--
size: 115
num of links: 1
sectors: 2 (--> 0 indirect blocks).

Inode Times:
Accessed:       1214677387 = Sat Jun 28 20:23:07 2008
File Modified:  1214678059 = Sat Jun 28 20:34:19 2008
Inode Modified: 1214678059 = Sat Jun 28 20:34:19 2008
Deletion time:  0

Direct Blocks: 41352

--------------Inode 5121-----------------------
Generation Id: 250453397
uid / gid: 0 / 0
mode: rrw-r--r--
size: 199490719
num of links: 1
sectors: 391162 (--> 765 indirect blocks).

Inode Times:
Accessed:       1214677387 = Sat Jun 28 20:23:07 2008
File Modified:  1214677704 = Sat Jun 28 20:28:24 2008
Inode Modified: 1214677704 = Sat Jun 28 20:28:24 2008
Deletion time:  0

Direct Blocks: 44545 44546 44547 44548 44549 44550 44551 44552 44553 44554 44555 44556
Indirect Block: 44557
Double Indirect Block: 44814
Tripple Indirect Block: 112207
Benötigt wird in deinem Fall die Inodekopie mit dem größtem size und den größten Zeitstempeln vor dem zerstören der File. Es ist wahrscheinlich die 2 Inodekopie, muss es aber nicht unbedingt sein, also ruig mal quer über die ganze Datei schauen.
Aus dieser Inode-Kopie benötigen wir die size und die 15 Blockverweise ganz unten, wenn du deine Datei auch auf die richtige Zeit zurückdatieren willst auch noch die Zeiten, muss aber nicht unbedingt sein.

* Das Ändern der Inode Daten
Jetzt wird es erst, wir müssen am offenem Herzen operieren. Das Programm dazu ist debugfs ein Tool das du bei der Installation mit der Unterstützung für ext2/ext3 Filesysteme schon installiert hast.
Code:
debugfs -w /dev/sdc1
öffnet dir mit diesem Tool das Filesystem, Achtung: es ist kein Schreibschutz aktiviert, also Änderungen werden auch wirklich geschrieben.
Das Tool meldet sich mit einem "debugfs: " als Prompt und erwartet Eingaben mit help könntest du Hilfe bekommen mit ls und cd dich durchs Filesystem navigieren mit quit das Tool wieder verlassen. usw.
Wir benötigen den Befehl zum Ändern der Inode (bitte Schreibweise für die <Inode> beachten, also in Größerals / Kleinerals einschachteln)
Code:
modify_inode <5121>
hier wird er jetzt die aktuellen Werte einzeln in [ ] anzeigen und du kannst den gewünschten Wert dahinter schreiben. Beim ersten Mal erst einmal alles nur mit Enter bestätigen, damit du erst einmal einen Überblick bekommst, was da so alles kommt. Danach kannst du ändern.
Code:
 modify_inode <5121>
                          Mode    [0100644]
                       User ID    [0]
                      Group ID    [0]
                          Size    [115] 199490719
                 Creation time    [1214678059]
             Modification time    [1214678059]
                   Access time    [1214677387]
                 Deletion time    [0]
                    Link count    [1]
              Block count high    [0]
                   Block count    [2]
                    File flags    [0x0]
                    Generation    [0xeed9d95]
                      File acl    [0]
           High 32bits of size    [0]
              Fragment address    [0]
               Direct Block #0    [41352] 44545
               Direct Block #1    [0] 44546
               Direct Block #2    [0] 44547
               Direct Block #3    [0] 44548
               Direct Block #4    [0] 44549
               Direct Block #5    [0] 44550
               Direct Block #6    [0] 44551
               Direct Block #7    [0] 44552
               Direct Block #8    [0] 44553
               Direct Block #9    [0] 44554
              Direct Block #10    [0] 44555
              Direct Block #11    [0] 44556
                Indirect Block    [0] 44557
         Double Indirect Block    [0] 44814
         Triple Indirect Block    [0] 112207
debugfs:  quit
Wenn du dich verhauen hast, mit Ctrl+C kommst du aus der aktuellen Bearbeitung ohne Änderung wieder heraus. Ansonsten wird scharf geschrieben. Geändert werden muss Size und die 12 "Direct Block" der "Indirect Block" der "Double Indirect Block" und der "Triple Indirect Block" auf die Werte die wir in der Inode-Kopie aus dem Journal herausgesucht haben. Richtig währe hier auch noch "Block count" mit den ausgelesenen Wert von sectors: also in diesem Beispiel mit "391162" zu belegen, bei mir ging es auch ohne, hat dann der Filesystemcheck für mich erledigt. Mit quit beenden wir das Tool danach wieder.

* der Filesystemcheck
Wir haben damit am Filesystem gravierende Änderungen gemacht, aber das Filesystem weiß noch nichts davon, es ist immer noch der Meinung es ist clean. Also müssen wir einen forcierten Filesystemcheck machen, dabei wird das Filesystem kräfig meckern.
Code:
rml100:/home/rob/test # fsck -f /dev/sdc1
fsck 1.40.2 (12-Jul-2007)
e2fsck 1.40.2 (12-Jul-2007)
Pass 1: Checking inodes, blocks, and sizes
Inode 5121, i_blocks is 2, should be 391162.  Fix<y>? yes

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
 differences:  -41352 +(44545--49152) +(49289--57344) +(57737--65536) +(65673--73728) +(74121--81920) +(82057--90112) +(90249--98304) +(98441--106496) +(106633--114688) +(114825--122880) +(123017--131072) +(131209--139264) +(139401--147456) +(147593--155648) +(155785--163840) +(163977--172032) +(172169--180224) +(180361--188416) +(188553--196608) +(196745--204800) +(205193--212992) +(213129--221184) +(221577--229376) +(229513--237568) +(237705--244413)
Fix<y>? yes

Free blocks count wrong for group #5 (7800, counted=3193).
Fix<y>? yes

Free blocks count wrong for group #6 (8062, counted=6).
Fix<y>? yes
.........
Wir lesen aufmerksam was er da angibt. beantworten aber "Fix<y>?" immer mit yes. Im einzelnen wird er an unserer geänderten Inode eventuell noch was zu merken haben, eine ganze Reihe von "Block bitmap"s ändern müssen und in jeder Blockgruppe die Anzahl der freien Blöcke korrigieren müssen. Am Ende dann aber doch irgendwann fertig sein
Code:
Free blocks count wrong for group #29 (8062, counted=1353).
Fix<y>? yes

Free blocks count wrong (996151, counted=800571).
Fix<y>? yes

/dev/sdc1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdc1: 12/131072 files (8.3% non-contiguous), 248005/1048576 blocks

* Fertig: und auch alle Daten wieder da ?
jetzt kann das Filesystem gemountet werden und sich die Datei mit ls und stat oder file angesehen werden, ob es wirklich auch wieder das kompimierte Tarachriv in voller Größe ist.
Einen Probelauf können wir starten und uns das Inhaltsverzeichnis ansehen, sollte dieser bis zum Ende ohne Fehlermeldung durchaufen, dann ist das Archiv auch wieder vollständig.
Code:
tar -tjvf Archivdatei
Wenn ja dann nie wieder bei Tar x und c verwechseln. :lol:

robi
 
OP
G

gundi

Member
Hallo Robi,
vielen vielen Dank für die sehr ausführliche Beschreibung deiner "Daten-Überschrieben-Anleitung". Ich werde es heute mal ausprobieren (natürlich an einem Image meines Dateisystems) und dir melden, wie es gelaufen ist. :D

PS: Das x und c für tar werde ich so schnell nicht mehr verwechseln :cry: .
 

Nilres

Member
Ich muss jetzt einfach mal Offtopic erwehen wie mega Geil das Tutorial ist und find das sehr nett von dir das du dir da soviel Mühe gegeben hast.

Mfg nils
 
OP
G

gundi

Member
Hallo Robi,
ich habe die Wiederherstellung der Datei durch die Veränderung des Inodes fast vollständig hinbekommen. Vielen Dank an dieser Stelle für deine großen Bemühungen. Lediglich bei den letzten sagen wir mal ca. 2-5 % bricht er die "Test-Dekomprimierung" mit folgender Meldung ab:
Code:
bzip2: Data integrity error when decompressing.
        Input file = (stdin), output file = (stdout)

It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.

You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.

tar: Unerwartetes Dateiende im Archiv.
tar: Nicht behebbarer Fehler: Programmabbruch.
Die von dem Decompress-Error betroffenen Daten sind nicht mehr von mir, sondern von meinem Bruder. Ich weiß noch nicht, ob diese für ihn relevant sind, würde aber vielleicht doch gerne das gesamte Archiv haben, da er sich auf meine Datensicherheit verlassen hatte. Wie kommt es, dass der letzte Teil korrupt ist?

Mit freundlichen Grüßen
Gundi

PS: Ich hatte wirklich heute Nacht schon Albträume gehabt die Daten zu verlieren :lol: :lol: .
 
A

Anonymous

Gast
gundi schrieb:
Wie kommt es, dass der letzte Teil korrupt ist?
In einer komprimierten File ist in der Regel an der Stelle Schluss, wenn ein Fehler aufgetreten ist. In diesem Fall ist an dieser Stelle ein falscher oder ein schon von irgend was anderem überschriebener Block oder ein unerwartetes Dateiende.
Schau noch mal die Datei mit den Inodes aus dem Journal an, ob du da vielleicht doch nicht den letzten Inodestand der alten Datei wiederhergestellt hast, oder ob da eine Inode dabei ist, die einen anderen 3fach indirekten Bockverweis hat. Oder ob du dich bei der Size eventuell doch mit einer der Zahlen verhauen hast? Irgendow dort sollte der Fehler liegen.

robi
 
OP
G

gundi

Member
Ich habe alle Punkte nochmal überprüft:
1. der von mir gewählte Inode-Stand ist definitiv der letzte
2. die Archivgröße zu dem Zeitpunkt ist maximal (im Verhältnis zu den anderen Inode-Zustandseinträgen)
3. bei mir haben die Blockverweise zu jedem Zeitpunkt den gleichen Wert (also ist der direkte Blockverweis 0, sowie alle anderen auch immer konstant geblieben). Somit kann ich keine anderen Werte übernehmen, als die, welche ich jetzt schon habe :roll:
4. ich habe mir mit dem Kommando debugfs die Werte des Inodes (bei mir war es 7667715) nochmals angeschaut und bemerkt, dass die Size nicht auf die Größe geändert wurde, die ich haben wollte. Im Protokoll von ext3grep bekomme ich eine Size von 11535364096 angezeigt. Wenn ich diese auf mein Tar-Archiv mit debugfs anwende und ein Filesystem-Check durchführe, kommt die Size auf maximal 4294967295. Woran das liegt weiß ich noch nicht. :?: :roll:


Mit freundlichen Grüßen
Gundi
 
A

Anonymous

Gast
gundi schrieb:
Wenn ich diese auf mein Tar-Archiv mit debugfs anwende und ein Filesystem-Check durchführe, kommt die Size auf maximal 4294967295.

Das wären ja nur so um die 30% du hattest jedoch geschrieben das du weit mehr wieder zusammenbauen konntest. Nehme mal an, das ist auf der Kopie gemacht worden, die den Filesystemcheck schon einmal hinter sich hatte.

Dann neuer Versuch mit neuer Kopie vom Orginal, wir versuchen die Daten jetzt mal aus einem dreckigem Filesystem ohne mount herauszukopieren. Allerdings benötigst du in deinem System dafür den Plattenplatz für das File, also ca. 12GB in einem Filesystem das auch solche großen Files zuläßt. (also zB nicht fat32) . Dann stellst du dich mit cd in das Filesystem in dem du diese min. 12GB Platz noch hast und öffnest wieder mit debugfs -w deine Kopie . Die Inode wie davor auch editieren, SIZE ändern, "Block count" auf den Wert von "sectors:" und die 15 Blockadressen alles auf die Werte aus dem Journal ändern. Dann aber keinen Filesystemcheck machen sondern gleich aus debugfs heraus mit
Code:
dump <INODE> testarchiv.tar.bz2
das ganze so zusammengewürfelte Archiv als testarchiv.tar.bz2 herauskopieren. Es landet dann in dem Verzeichnis in dem du dich beim Aufruf von debugfs befunden hast. debugfs verlassen, das Archiv auf Vollständigkeit hin überprüfen. ls sollte die angegebene Size als Große anzeigen, und tar -tvjf das Archiv komplett auflisten können.
Wenn das auch jetzt noch nicht vollständig sein sollte. Dann mal die Ausgabe der kompletten Inode-Daten und Blockverlinkung mit folgendem Befehl in eine Datei schreiben
Code:
debugfs -R "stat <INODE>" /dev/.... > INODEstat.out
dann überlegen wir uns mal wie ich an diese Datei komme,( dürften bei 3,2 Millionen Blöcken eventuell etwas größer werden) und wie wir herausbekommen ab welchem Block das Archiv fehlerhaft ist. Dann müssten wir nach den Kopien des Blockverweisblöckes suchen, der damit im Zusammenhang stehen könnte. Das wird dann aber schon sehr sehr aufwendig.

robi
 
OP
G

gundi

Member
Hallo,
leider waren die regenerierten Daten im Tar-Archiv bei deiner zweiten Anleitung noch deutlich weniger, als bei der ersten (ich habe hierfür natürlich immer Abbilder verwendet).
Hier ist die Ausgabe von ext3grep. Ich kann leider nicht alles Posten, da es beim Forum offensichtlich eine Zeilenbeschränkung gibt. Doch ich kann definitiv sagen, dass die Einträge, die weiter unten folgen von der Size immer kleiner sind, als der Eintrag mit 11541647360:

Code:
Running ext3grep version 0.7.0
WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set. This either means that your partition is still mounted, and/or the file system is in an unclean state.
Number of groups: 895
Minimum / maximum journal block: 1545 / 35886
Loading journal descriptors... sorting... done
Journal transaction 4422 wraps around, some data blocks might have been lost of this transaction.
Number of descriptors in journal: 28119; min / max sequence numbers: 461 / 5157
Copies of inode 7667715 found in the journal:

--------------Inode 7667715-----------------------
Generation Id: 1000130763
uid / gid: 1000 / 100
mode: rrwxr-x---
size: 118
num of links: 1
sectors: 8 (--> 0 indirect blocks).

Inode Times:
Accessed:       1213975287 = Fri Jun 20 17:21:27 2008
File Modified:  1213975104 = Fri Jun 20 17:18:24 2008
Inode Modified: 1213975104 = Fri Jun 20 17:18:24 2008
Deletion time:  0

Direct Blocks: 15362048

--------------Inode 7667715-----------------------
Generation Id: 1000130763
uid / gid: 1000 / 100
mode: rrwxr-x---
size: 0
num of links: 1
sectors: 8 (--> 1 indirect block).

Inode Times:
Accessed:       1213974896 = Fri Jun 20 17:14:56 2008
File Modified:  1213975059 = Fri Jun 20 17:17:39 2008
Inode Modified: 1213975059 = Fri Jun 20 17:17:39 2008
Deletion time:  0

Direct Blocks: 15341568

--------------Inode 7667715-----------------------
Generation Id: 1000130763
uid / gid: 1000 / 100
mode: rrwxr-x---
size: 135
num of links: 1
sectors: 8 (--> 0 indirect blocks).

Inode Times:
Accessed:       1213974896 = Fri Jun 20 17:14:56 2008
File Modified:  1213975050 = Fri Jun 20 17:17:30 2008
Inode Modified: 1213975050 = Fri Jun 20 17:17:30 2008
Deletion time:  0

Direct Blocks: 15337473

--------------Inode 7667715-----------------------
Generation Id: 1000130763
uid / gid: 1000 / 100
mode: rrwxr-x---
size: 137
num of links: 1
sectors: 8 (--> 0 indirect blocks).

Inode Times:
Accessed:       1213974896 = Fri Jun 20 17:14:56 2008
File Modified:  1213974922 = Fri Jun 20 17:15:22 2008
Inode Modified: 1213974922 = Fri Jun 20 17:15:22 2008
Deletion time:  0

Direct Blocks: 15355904

--------------Inode 7667715-----------------------
Generation Id: 1000130763
uid / gid: 1000 / 100
mode: rrwxr-x---
size: 0
num of links: 1
sectors: 7975792 (--> 996974 indirect blocks).

Inode Times:
Accessed:       1213974896 = Fri Jun 20 17:14:56 2008
File Modified:  1211709932 = Sun May 25 12:05:32 2008
Inode Modified: 1211663602 = Sat May 24 23:13:22 2008
Deletion time:  0

Direct Blocks:
Tripple Indirect Block: 16420320

--------------Inode 7667715-----------------------
Generation Id: 1000130763
uid / gid: 0 / 0
mode: rrw-r--r--
size: 11541647360
num of links: 1
sectors: 22564328 (--> 4292872900 indirect blocks).

Inode Times:
Accessed:       1211650540 = Sat May 24 19:35:40 2008
File Modified:  1211663596 = Sat May 24 23:13:16 2008
Inode Modified: 1211663596 = Sat May 24 23:13:16 2008
Deletion time:  0

Direct Blocks: 15345664 15345665 15345666 15345667 15345668 15345669 15345670 15345671 15345672 15345673 15345674 15345675
Indirect Block: 15345676
Double Indirect Block: 15346701
Tripple Indirect Block: 16420320

--------------Inode 7667715-----------------------
Generation Id: 1000130763
uid / gid: 0 / 0
mode: rrw-r--r--
size: 11535364096
num of links: 1
sectors: 22552048 (--> 4292872899 indirect blocks).

Inode Times:
Accessed:       1211650540 = Sat May 24 19:35:40 2008
File Modified:  1211663591 = Sat May 24 23:13:11 2008
Inode Modified: 1211663591 = Sat May 24 23:13:11 2008
Deletion time:  0

Direct Blocks: 15345664 15345665 15345666 15345667 15345668 15345669 15345670 15345671 15345672 15345673 15345674 15345675
Indirect Block: 15345676
Double Indirect Block: 15346701
Tripple Indirect Block: 16420320

... usw ... usw ... usw ... leider kann ich nicht alles Posten......................................
Ich habe noch eine Frage: Bei dem oben gelisteten Inode-Protokoll gibt es für "sectors" immer zwei Werte einen außerhalb und einen innerhalb der Klammer, welcher ist bei der Wiederherstellung zu verwenden? Beispiel:
Code:
sectors: 22539808 (--> 4292872897 indirect blocks).
Wenn ich wüsste, welche Dateianhänge in diesem Forum zulässig sind, dann könnte ich euch die Protokolldateien hochladen.
Aber hier erstmal die Links zu den Dateien:
http://gilgames.gi.funpic.de/tmp/ext3grep-inode-7667715.txt
http://gilgames.gi.funpic.de/tmp/debugfs-inode-7667715.txt (bei dieser Datei muss viel nach rechts gescrollt werden :D :D )

Danke für die großartige Arbeit von euch (hier ist vorallem Robi an erster Stelle zu erwähnen).
 
A

Anonymous

Gast
Ich habe mir die Daten die du geliefert hast einmal durchgeschaut. Auf dem Filesystem ist doch mehr passiert als du angenommen hast.
Auch sind einige Unklarheiten enthalten, die so nicht zu interpretieren sind, wenn man nicht genau nachvollziehen kann was du wann gemacht hast Zumal man nicht immer genau weiß aus welcher Situation jetzt genau die Logdaten kommen und was vorher schon alles passiert ist. Unklarheiten zB. Änderung an den Zugriffsrechten :?: :?: :?: User- +Gruppenzugehörigkeite :?: :?: :?: War das Filesystem jetzt doch noch gemountet bei der Abgabe des ext3grep oder nicht. Das Archiv ist am Anfang und am Ende jedenfalls ok. Allerdings scheint ein Indirekt verweisender Block defekt oder überschrieben. 17432222
Was da mit diesem und eventuell benachbarten Blöcken passiert ist ??? Die Datenstruktur ist dort an dieser Stelle unnormal für ein Filesystem in dem reichlich Platz ist und es sieht nicht so aus, das das schon bei der Erstellung des Archives passiert ist.
(IND):17431197
(2043916-2044939):17431198-17432221
(IND):17432222
????????????????????????????????????????????
(IND):17433767
(2045964-2046987):17433768-17434791
(IND):17434792
dadurch fehlen an dieser Stelle 1024 Blöcke oder 4MB Daten. Da es sich um ein komprimiertes Archiv handelt sind die Daten die danach im Filesystem wieder ok sind, allerdings auch nicht mehr wiederzugewinnen.

Für weiter Versuche müsste man wirklich das Filesystem vor sich haben, denn an dieser Stelle wird es dann recht kompliziert wenn man doch noch versuchen will an die kompletten Daten zu kommen. Das ist hier übers Forum nicht mehr zu machen.

robi
 
OP
G

gundi

Member
Hallo Robi und alle anderen Linux-Club Kollegen,
danke für eure große Mühe (war in letzter Zeit kaum am Rechner gewesen, deshalb keine Zeit zum danken gehabt :lol: ). Ich habe sämtliche Daten nach ewigem hin und her mit den vielen Abbildern (ich habe 4 Festplatten mit je 80GB-320GB) und mit Hilfe meiner beschädigten Festplatte wiederhergestellt bekommen.
Ich hatte ja bereits erwähnt, dass bestimmte Sektoren meiner Notebookfestplatte für das Dateisystem unlesbar gewesen waren. Darauf hin habe ich ein Filesystem-Check (kurz fsck) darauf laufen lassen und sämtliche Meldungen (das waren ca. 500-2000) zur Reparatur mit "yes" bestätigt. Ich habe den Griff einer Zange auf die "y"-Taste zum unbeaufsichtigten Bestätigen gestellt 8) :lol: :lol: .
Danach habe ich alle Daten auf DVDs gebrannt (ca. 8x DVDs waren nötig) und mein System wiederhergestellt.

Danke an alle nochmal. Ihr seid die besten. "Schleim"-Ende :wink:

------------------------ Nachtrag -------------------------
Wie kann man diesen Thread als gelöst markieren oder können das nur Moderatoren?
 
Oben