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

[gelöst] Festplatte aus Versehen falsch beschrieben

Spielwurm

Advanced Hacker
Ich habe aus Unachtsamkeit eine große Festplatte mit Spielfilmen drauf mit dem Opensuse-Netzwerk-Image beschrieben (dd). Danach wollte ich die Aktion, die eigentlich einer SD-Karte galt, wieder rückgängig machen und habe der vermeintlichen SD-Karte eine Partition verpasst vom Typ Fat32 und anschließend das entsprechnde Filesystem draufgeschrieben. Damit habe ich ja noch kaum was vernichtet und ich vermute, dass ich mit Photorec das meiste wieder herstellen kann. Aber: ist es ratsam, für Photorec den Orginaltyp mit dem Orginaldateisystem draufzuschreiben? Schafft Photorec eigentlich Filme? Ich habe es mehrfach benutzt, aber nur für wenige Dokumente und viele Fotos.

Spielwurm
 
A

Anonymous

Gast
Spielwurm schrieb:
Schafft Photorec eigentlich Filme? Ich habe es mehrfach benutzt, aber nur für wenige Dokumente und viele Fotos.
kommt 1. auf das genaue Dateiformat an, das die Videos hatten. bei MPEG gibts zB. mit Sicherheit viel Filmsalat. Photorec sucht nach Mpeg-Blocks und die kommen regelmäßig alle paar zig. Blocks genau an die Dateiblockanfänge, das sieht für Photorec dann alles gleich aus, keine Möglichkeit zu erkennen, noch alte Datei oder jetzt Dateineuanfang, ....jetzt lieber mal einen Neuanfang ... gibt lauter Einzelsequenzsalat den niemand jemals wieder zusammenschneiden kann.
Andere Video-Dateitypen? Ein paar gehen gut, andere gar nicht, aber sehr große Dateien ????????

Bei großen Filmen, kommt noch zusätzlich ins Spiel ext3 ? oder doch ext4 ? oder war da was anderes drauf?. Photorec hat keine Ahnung was ext4 ist bzw. wie dort sehr große Dateien abgelegt werden und findet nur das als Datei was als ein zusammengehöriger Block zu finden ist. Sehr große Dateien sind aber auch dort in mehr oder weniger Großen Segmenten abgelegt, und damit kommen wir zu Punkt 3. wie wurden die Filmdateien geschrieben. Download mit Dateibrowser aus dem Netz, und möglichst 2 oder mehrere parallel. sehe ich weder ext4 noch ext3 und Photorec Chancen. Festplatte schon lange in Benutzung und war schon mehrfach voll, es wurden immer wieder Dateien gelöscht und neue geschrieben, dann kannst du auch hier mit einer zünftigen Fragmentierung großer Videodateien rechnen. Dateien einzeln und schnell auf leere Platte geschrieben, schöne große Segmente möglich, aber langsam und gleichzeitig mehrere Dateien geschrieben, dann wäre die nächste Frage mit welchem Programm geschrieben. Dummes Programm, extrem viele Segmente............ intelligentes Programm könnte eventuell während des Schreibens immer wieder viel Platzplatz reserviert haben, um große Segemente schreiben zu können aus bei parallelen Schreibvorgängen.

Du kannst Photorec versuchen, glaube aber nicht das du dort große Erfolge feiern wirst. Lass die Platte so wie sie ist, und sag photorec was es für Dateisystemtype gewesen sein sollte.

hast du zufällig noch eine Kopie oder eine Idee von der original Partitionstabelle?

ext3 oder ext4 und wenn das Image das du da drauf gebügelt hast nicht allzugroß war, dann ist ein weitestgehendes Erstellen einer Kopie mit hoher Prozentzahl an unbeschädigten Dateien sehr gut möglich mit zB eine ähnlichen Vorgehensweise. Aber ohne Kopie oder Idee von der orig. Partitionstabelle wäre das komplizierte Handarbeit die erforderlichen Voraussetzungen auf der Platte wiederherzustellen, die übers das Forum hier kaum machbar ist.

robi
 
OP
S

Spielwurm

Advanced Hacker
Die Festplatte wurde fast ausschließlich nach und nach beschrieben per Avidemux mit Filmen im Mpeg und Avi-Format, die per Sat-TV aufgezeichnet worden sind. Kein Film unter 2GB. Das Image war 250MB groß, hat mir also höchstens den ersten Film weggeschossen. Sie hatte genau eine Partition, nämlich die, die fdisk freiwillig vorschlägt (ab 2048 bis Ende), und das Dateisystem war EXT4. Ergo kann ich die Partitionstabelle sofort wieder herstellen. Gibt es nicht ein Backup des Inhaltsverzeichnisses am Ende der Partition? Wenn ja, dann müsste man doch mit der Angabe EXT4 und diesem Backup den Inhalt wieder herstellen können?

Spielwurm

PS: ich schreib da nicht drauf, eine gleich große Platte ist bestellt wg. 1:1-Kopie ...
 

spoensche

Moderator
Teammitglied
Womit hast du das Image erstellt?

Unter Umständen kannst du das Image ohne weiteres auch so mounten.
 
OP
S

Spielwurm

Advanced Hacker
@spoensche
Opensuse-Netzwerk-Image
Wenn Du von USB-Stick eine Installation durchführen möchtest, dann kannst Du Dir eine ISO-Datei für eine Netzwerkinstallation von Opensuse runterladen. Wenn Du das dann mit dd auf einen USB-Stick schreibst, kann Du davon booten. Möchtest Du noch den kompletten dd-Befehl?

Spielwurm
 
A

Anonymous

Gast
Spielwurm schrieb:
Das Image war 250MB groß, hat mir also höchstens den ersten Film weggeschossen.
;) wenn das so einfach wäre, du hast dir die Inode- und Blockallokationstabellen der ersten wahrscheinlich 6 oder 8 Blockgruppen zerschossen, und 2 Blockgruppen komplett überschrieben, die Daten des Root-Verzeichnisses, also mindestens alle Namen und Verzeichnisse der ersten Ebene. und eventuell mehrere große Dateien beschädigt, da mindestens die erste Blockgruppe die du gebügelt hast gerne auch genommen wird für Fragmente von größeren Dateien, wenn nicht genügend kleine Dateien und Verzeichnisse zB im Rootverzeichnis erstellt werden. Also ist nicht so, das da alles der Reihe nach auf die Platten geschrieben wird, das erfolgt nach ganz anderen Regeln.

Eine Frag noch, was ist auf dem Image für ein Dateisystem? Wenn es dummerweise ext2/3/4 sein sollte, dann sollte eventuell vorher nochmal 250MB NULLen auf die Platte geschrieben werden, damit es bei der Wiederherstellung nicht zu einer eventuellen Vermischung von Inodetabenblöcken, aus verschiedenen Dateisystemen kommen könnte. Auch defekte Dateien würden sich besser finden lassen, die hätten dann irgendwo größere Mengen Nullen anstatt irgendwelcher zufälliger Bytes aus dem Image. Aber erst mal noch nichts dergleichen machen. Die Bytegenaue Größe des Images bitte noch liefern.

Spielwurm schrieb:
Sie hatte genau eine Partition, nämlich die, die fdisk freiwillig vorschlägt (ab 2048 bis Ende), und das Dateisystem war EXT4. Ergo kann ich die Partitionstabelle sofort wieder herstellen.
Diese Partitionstablelle müsste wieder drauf, wenn die passt, und zwar genau passt, dann funktioniert dieses Script hier. Einfach starten wie folgendes Beispiel:
Code:
./script.sh  /dev/sdc1
das Script ändert nichts, das versucht nur Kopien von Superblöcken zu finden. und baut daraus mögliche Befehleszeilen für das Recovern mittels ext4magic.

Spielwurm schrieb:
Gibt es nicht ein Backup des Inhaltsverzeichnisses am Ende der Partition? Wenn ja, dann müsste man doch mit der Angabe EXT4 und diesem Backup den Inhalt wieder herstellen können?
kommt auf den Partitionstabellentype an, und der ist uA auch abhängig von der Diskgröße, ist die Disk denn größer 2TByte ? dann hättest du auf alle Fälle einen GPT drauf, der hat die Partitionstabelle auch noch am Ende. aber dann geht wahrscheilich gar kein fdisk, ich hab mit GPT da auch keine Ahnung und Erfahrungen wie man sowas reparieren kann, hab ich noch nicht mit rumgespielt.

Wenn das Script vernünftige Ausgaben macht, und ich die gesehen haben, dann kannst du ext4magic installieren. Opensuse sollte passende Pakete im default Repo haben.
Die 2. Platte würdest du dazu aber für das Wiederherstellen der Daten benötigen. ext4magic ändert an den Daten auf der "kaputten" Platte nichts, sondern kopiert alles raus was es findet.

Reparatur mit fsck und entsprechenden Parametern wäre auch möglich, bei diesem Fehler :???: würdest du hinterher alles im lost&found finden, fsck ist sehr penibel und wird hier nicht wirklich alle Dateien reparieren wollten und einiges versenken was ext4magic finden würde, die Verzeichnisstruktur würde weitestgehend zerfledert. Und Wichtig: was an Metadaten fsck aus welchen Gründen auch immer ändert, ist nicht mehr rückgängig zu machen, und die betroffenen Dateien dann anschließend auch mittels ext4magic nicht mehr zu recovern. Für einen Versuch mit fsck würde man also eine Kopie der Platte vorher anlegen müssen.

Aber erstmal will ich die Ausgaben des Scripts hier sehen. dann schauen wir uns erst noch eine der gefundenen Superblockkopien an und prüfen die genaue Größe von Dateisystem und Partition. Vorher bitte keine Reparaturversuche unternehmen, nur derzeitige falsche Partitionstabelle löschen und erste Partition neu über die ganze Platte anlegen.


robi
 

josef-wien

Ultimate Guru
robi schrieb:
Eine Frag noch, was ist auf dem Image für ein Dateisystem?
Nach
Code:
dd if=openSUSE-13.1-NET-x86_64.iso of=/dev/sdh
gibt es 2 Partitionen:
Code:
fdisk -l /dev/sdh

Platte /dev/sdh: 4011 MByte, 4011614208 Byte
64 Köpfe, 32 Sektoren/Spur, 3825 Zylinder, zusammen 7835184 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x46be3d1a

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sdh1             280        8471        4096   ef  EFI (FAT-12/16/32)
/dev/sdh2   *        8472      581631      286580   17  Verst. HPFS/NTFS
Eingehängt ist dann aber der gesamte Datenträger:
Code:
cat /proc/mounts | grep sdh
/dev/sdh /media/openSUSE-13.1-NET-x86_640091 iso9660 ro,nosuid,nodev,noatime,uid=1000,gid=100,iocharset=utf8,mode=0400,dmode=0500 0 0

mount | grep sdh
/dev/sdh on /media/openSUSE-13.1-NET-x86_640091 type iso9660 (ro,nosuid,nodev,noatime,uid=1000,gid=100,iocharset=utf8,mode=0400,dmode=0500,uhelper=udisks)
Wenn ich das ISO-Image vom Konqueror einhängen lasse, schaut es ähnlich aus:
Code:
cat /proc/mounts | grep loop
/dev/loop0 /mnt/iso-image iso9660 ro,relatime 0 0
 
OP
S

Spielwurm

Advanced Hacker
@robi
Die IMG-Größe: 258.998.272 Byte
Dass ich mir ziemlich heftig die Disktabellen überschrieben habe, ist mir schon klar. Deswegen frage ich ja nach der besten Vorgehensweise, weil ich mich mit solchen Fehlern noch nicht befassen durfte. Ich danke vorab für die Hilfe und melde mich nach Weihnachten wieder, ich muss erst eine gleichgroße Platte haben und Ruhe! Die Platte ist übrigends nicht größer als 2TB.

Spielwurm
 
OP
S

Spielwurm

Advanced Hacker
Ich habe die Partition wieder im ursprünglichen Zustand eingetragen
Code:
/dev/sdg1            2048  3907029167  1953513560   83  Linux
und das Script ausgeführt. Ausgabe:
Code:
Jupiter:/home/hartmut # Rettungsscript.sh /dev/sdg1
ext4magic "/dev/sdg1" -s 4096 -n 294912 -c -D
ext4magic "/dev/sdg1" -s 4096 -n 819200 -c -D
ext4magic "/dev/sdg1" -s 4096 -n 884736 -c -D
ext4magic "/dev/sdg1" -s 4096 -n 1605632 -c -D
ext4magic "/dev/sdg1" -s 4096 -n 2654208 -c -D
ext4magic "/dev/sdg1" -s 4096 -n 4096000 -c -D
ext4magic "/dev/sdg1" -s 4096 -n 7962624 -c -D
ext4magic "/dev/sdg1" -s 4096 -n 11239424 -c -D
ext4magic "/dev/sdg1" -s 4096 -n 23887872 -c -D
ext4magic "/dev/sdg1" -s 4096 -n 71663616 -c -D
ext4magic "/dev/sdg1" -s 4096 -n 78675968 -c -D
ext4magic "/dev/sdg1" -s 4096 -n 102400000 -c -D

Spielwurm
 
A

Anonymous

Gast
Gut und Schlecht

Gut, der Partitionsanfang stimmt 100%, das ist schon mal sehr gut, ich nehme mal an die Paritition wird dann auch die Länge haben wie vorher und nicht kleiner als das Dateisystem sein. Damit brauchst du dort nicht weiter rumspielen, und könntest ext4magic dort direkt so laufen lassen.

Schlecht, du hast mehr zerstört als angenommen, es sind nicht nur 2 Blockgruppen beschädigt, sondern 6 oder mehr. also Minumum 786MB . Erster unbeschädigte Superblock scheint die 5. Kopie des Superblocks in der 9. Blockgruppe zu sein , also 1GB hinter dem Filesystemanfang. Wahrscheinlich keine komplette Zerstörung in den Bereichen nach 256MB. aber. :???: soviel zu dieser Aussage:
Spielwurm schrieb:
Danach wollte ich die Aktion, die eigentlich einer SD-Karte galt, wieder rückgängig machen und habe der vermeintlichen SD-Karte eine Partition verpasst vom Typ Fat32 und anschließend das entsprechnde Filesystem draufgeschrieben. Damit habe ich ja noch kaum was vernichtet
Also schon eine ordentliche Beschädigung die du dort reingezaubert hast.

Benötig werden würde folgendes Paket: ext4magic bei OpenSuse 12.3 im Standard repo ist V 0.3.0, das sollte für deine Belange reichen,
V 0.3.1 gäbe es für 12.3 hier im repo.

Wenn die neue Platte da ist, ein ext3 oder ext4 Dateisystem drauf und nach /mnt mounten. Dort hin soll recovert werden. (Versuche nicht auf ein cifs nfs oder ntfs zu revovern, das würde nicht funktionieren.)
Darauf achten das deine defekte Platte wieder als /dev/sdg1 im System ist. (oder Befehl entsprechend anpassen)
Code:
ext4magic "/dev/sdg1" -s 4096 -n 1605632 -c -D  -d /mnt/RECOVER
und ein paar Stunden beten. Wegen der eventuell nicht wiederherstellbaren Gesamtverzeichnisstruktur ( dazu müsstest du sehr viel Glück mit den Journaldaten haben) sollte das meiste dann unter /mnt/RECOVER/MAGIC-1 als größere Dateibaumsegmente zu finden sein. Unterhalb /mnt/RECOVER/MAGIC-2 eventuell noch einige Einzeldateien ohne Namen,


viel Glück.

robi
 
OP
S

Spielwurm

Advanced Hacker
Danke robi, die Platte ist schon da. Ich werde aber doch erst nach Weihnachten da ran gehen.
Du hast mehr zerstört als angenommen, es sind nicht nur 2 Blockgruppen beschädigt, sondern 6 oder mehr. also Minumum 786MB .
Was das angeht: was ist schon 1GB, wenn es um 1500GB Spielfilme in bester HD-Qualität geht ....

Spielwurm
 
OP
S

Spielwurm

Advanced Hacker
Ergebnis des Recovery-Versuchs:
@robi
ext4magic hat 24 Dateien ausgespuckt, davon 10 avi und 14 mpg. Das ist eine Erfolgsrate von 10%. Inzwischen habe ich mich bei http://openfacts2.berlios.de/wikide/index.php/BerliosProject:Ext4magic in das Programm eingelesen. Die Optionen in der Befehlszeile von Dir finde ich nicht: -c und -D. gibts von den Optionen, die ich nicht finde, noch mehr?

Zusätzlich habe ich Photorec an die Platte geschickt mit diesem Ergebnis: von 100 mpg-Dateien 98 gefunden, davon waren 50% schon sauber, die anderen 50% musste ich nochmal durch ProjectX schicken, es war zuviel Müll hinten dran (eine mpg 130GB, viele um die 20GB). Aber die 98 mpg-Filme habe ich.

Bei den HD-Filmen im avi-Container sieht es schlecht aus: Photorec findet ziemlich alle Dateianfänge, aber die ausgeworfenen Dateien sind meist 1GB, viele 2GB und wenige bis 4GB groß. Niemals ist ein Film ganz vorhanden (bis auf die von ext4magic gefundenen).

Hast Du noch Tipps auf Lager?

Spielwurm
 
A

Anonymous

Gast
Spielwurm schrieb:
Ergebnis des Recovery-Versuchs:
ext4magic hat 24 Dateien ausgespuckt, davon 10 avi und 14 mpg. Das ist eine Erfolgsrate von 10%. Inzwischen habe ich mich bei http://openfacts2.berlios.de/wikide/index.php/BerliosProject:Ext4magic in das Programm eingelesen. Die Optionen in der Befehlszeile von Dir finde ich nicht: -c und -D. gibts von den Optionen, die ich nicht finde, noch mehr?
ist in der Manpage oder hier beschrieben.

Es sind die Blockdaten von mindestens der ersten 15 Blockgruppen überschrieben. Das so wenig gefunden wurden könnte zB bedeuten, du hattest eine sehr flache Verzeichnisstruktur im Dateisystem. Aus den Journaldaten wird bei dieser Verwendung des Filesystems nicht viel zu erwarten sein. Beim langsamen Schreiben zB. während eines Downloades oder beim Abspielen von Videos wird im Journal fortwährend immer nur ein einziger Inodeblock geschrieben, und in einem Inodeblock befinden sich bei dir nur 8 Inode, und ob gerade diese alle 8 auch belegt sind, ist dann die nächste Frage. Und irgendwann ist der Ringbuffer im Journal voll, und dann sind da eben nur noch alte Journaldaten von sehr wenigen Dateien im Journal vorhanden. Die anderen Inodeblöcke wären zB in Journal geschrieben worden, wenn du zB. ein find hättest laufen lassen, oder anders dort mal ein paar andere Dateien und Verzeichnisse angefasst hättest. Aber bei dieser Verwendung ist es eben nun mal so, das immer längere Zeit nur eine Datei in Bearbeitung ist, und dann ist eben aus dem Journal nicht viel Unterschiedliches herauszuholen.
Gibt noch ein paar mehr mögliche Gründe warum dort nicht allzuviel gefunden wurde, dazu müsste man sich aber die Daten im defekten Dateisystem von innen genauer anschauen.

Schade, hat nicht sollen sein, aber das Recovern über Inode ist die einzige offizielle Methode in ext4magic für deinen Fall, das auf ext4 optimierte integrierte Recovern über Filecarving ist in ext4magic nur auf gelöschte Dateien geschaltet. und bei dir sind sie nicht gelöscht.

Spielwurm schrieb:
Zusätzlich habe ich Photorec an die Platte geschickt mit diesem Ergebnis: von 100 mpg-Dateien 98 gefunden, davon waren 50% schon sauber, die anderen 50% musste ich nochmal durch ProjectX schicken, es war zuviel Müll hinten dran (eine mpg 130GB, viele um die 20GB). Aber die 98 mpg-Filme habe ich.

Bei den HD-Filmen im avi-Container sieht es schlecht aus: Photorec findet ziemlich alle Dateianfänge, aber die ausgeworfenen Dateien sind meist 1GB, viele 2GB und wenige bis 4GB groß. Niemals ist ein Film ganz vorhanden (bis auf die von ext4magic gefundenen).
Filecarving bei Videodateien ist eine Sache für sich, es gibt alleine ein dutzend Containerformate in die das reingepackt sein kann. Einige Containerformate lassen sich gut, wenn auch aufwendig, verfolgen, einiges geht auch nur mittels Kaffeesatzleserei, und dieses versagt dann bei großen Dateien ziemlich sicher. In Photorec sind nur ein wenige mögliche Video Formate einigermaßen aufwendig programmiert. Ich kenne aber kein Opensource Programm das dieses besser könnte. Was andere kommerzielle Tools versprechen ist immer sehr vollmundig, ob sie es halten können eine andere Frage, ich habe nur eines mal ausprobiert, und das war ernüchternt.

robi
 
OP
S

Spielwurm

Advanced Hacker
Danke. Kannst Du die Platte so-wie-sie-ist gebrauchen für Deine weitere Arbeit an ext4magic?

Spielwurm
 
A

Anonymous

Gast
Spielwurm schrieb:
Danke. Kannst Du die Platte so-wie-sie-ist gebrauchen für Deine weitere Arbeit an ext4magic?
Danke , aber das nützt so nichts, ich kann mir alle Möglichen und Unmöglichen Konstellationen gezielt zusammenbauen. Wäre was anderes wenn du in einen reproduzierbaren Bug, einer Endlosschleife oder anderen Laufzeitfehler gelaufen wärst. dann hätte ich ein paar Infos aus dem Filesystem schon gerne gehabt.
Für manuellen Recover habe ich die nächsten Monaten auch keine Zeit. Dazu sind deine Daten wohl auch nicht wichtig genug, dass sich so ein Aufwand lohnen würde.

robi
 
Oben