Gelöst: festplatten-partitionierungs-problem

[ryal]

Hallo allerseits,
Ich nutze seit kurzer Zeit Debian Sarge. Ich habe vorher jahrelang SuSE genutzt, nach dem Kauf dieses PCs aber zunächst Windows XP laufen gelassen und jetzt wieder gewechselt.
Nun also zu meinem Problem:
Von meiner Windowszeit an diesem Rechner blieben drei Partitionen übrig, die allesamt NTFS als filesystem hatten. Das waren:
/dev/hda5
/dev/hda6
/dev/hda7
(/dev/hda1 war/ist als / gemounted, /dev/hda8 als swap => übernommene debianinstallervorgaben, sonst gabs keine partitionen)

Da NTFS auch mit captive keinen für mich alltagstauglichen writesupport bietet, ich aber die dateien von /dev/hda6 und /dev/hda7 noch brauchte, machte ich mich ans fröhliche Daten-hin-und-herverschieben, indem ich zuerst die /dev/hda5 per mkfs.reiserfs formatierte, daten auf diese verschob, die "neue" partition ebenfalls zu reiserfs formatierte und auch darauf daten verschob.
Das funktionierte alles perfekt.
Danch kam mir der gedanke, die übriggebliebene, leere Partition mit meiner / partition zu verbinden und somit den gesamten speicherplatz nutzbar zu machen. Wie gesagt, mir kam nur der Gedanke, denn so weit gekommen bin ich nicht. Per Suchfunktion dieser Seite stieß ich auf Parted mit seinem Frontend qtparted, welches ich startete, mir meine partitionen besah und testeshalber die leere partition erstmal nur löschte (ohne es auszuführen, klar, laut manual wird auch vorher nichts übernommen)
Das Programm schloss sich prompt und hinterließ im terminal die anzeige "reiserfs support not implemented yet". Danach fuhr ich aus anderen Gründen meinen Rechner normal runter (nachdem ich die daten verschoben hatte, hab ich alle platten unmounted, sicher ist sicher, und beim runterfahren gab es auch keinen fehler)

Nach dem Hochfahren stellte ich folgendes fest:
- Meine Partitionen /dev/hda5 bis /dev/hda7 scheinen alle leer zu sein
- fdisk -l zeigt mir an, dass /dev/hda5 mein swap ist, /etc/fstab weiss davon allerdings nichts
- Der dadurch entstandene schluss, dass vielleicht meine daten auf /dev/hda8 liegen lässt sich ein stück weit bestätigen: Meine Daten vom früheren /dev/hda6 (welche bei der aktion auf /dev/hda5 verschoben wurden) sind dort zu finden.

Es "fehlt" eine ganze Partition voller Daten.
- /dev/hda7 ist leer
- /dev/hda6 enthält den ordner "lost and found" und sonst nichts (wobei ich keine ahnung habe wo der ordner her kommt, er ist auch leer)

- /dev/hda5 ist ebenfalls leer
Ich finde es jedenfalls besorgniserregend, dass ich meinen angeblichen swap so ohne weiteres mounten kann, ich meine in erinnerung zu haben, dass das nicht normal ist.

Ein Blick auf df -h sagt mir, dass /dev/hda5 wirklich meine swapausmaße hat, und auf /dev/hda6 anscheinend meine verlorenen daten liegen...

Habt ihr irgendwelche vorschläge, wie ich an diese daten rankomme? sie sind wirklich wichtig...!
Und ehe jemand danach fragt: ich habe keine backups gemacht (hatte weder die möglichkeit, noch die veranlassung, da ich ja nur daten umherschob, ich weiß: wer den schaden hat...), und die suchfunktion dieser Seite sowie Google nach bestem Wissen genutzt... Falls ich etwas übersehen hab wäre ich um hinweise dankbar...

[ryal]

Ich habe heute nochmals versucht, dem Fehler etwas auf die Spur zu kommen und habe daten erhalten, die mich noch mehr verwirren.
file -s /dev/hda5,7 und 8 ergeben

Code: Alles auswählen

/dev/hda5: data

Aber file -s /dev/hda6 ergibt

Code: Alles auswählen

 /dev/hda6: Linux rev 1.0 ext2 filesystem data
 

Testdisk 5.2 war auch nicht hilfreich, er hat einen "Read error" bei jedem einzelnen cylinder, den er anfangs zu analysieren versucht
gpart zeigt folgendes an (/dev/hda6 war während des vorgangs gemounted, befehl für gpart war " gpart /dev/hda")

Code: Alles auswählen

Begin scan...
Possible partition(Linux ext2), size(9554mb), offset(0mb)
Possible extended partition at offset(9554mb)
End scan.

Checking partitions...
Partition(Linux ext2 filesystem): primary
Ok.

Guessed primary partition table:
Primary partition(1)
   type: 131(0x83)(Linux ext2 filesystem)
   size: 9554mb #s(19567104) s(63-19567166)
   chs:  (0/1/1)-(1023/254/63)d (0/1/1)-(1217/254/60)r

Primary partition(2)
   type: 015(0x0F)(Extended DOS, LBA)
   size: 66785mb #s(136777410) s(19567170-156344579)
   chs:  (1023/254/63)-(1023/254/63)d (1218/0/1)-(9731/254/63)r

Primary partition(3)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(4)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

[ryal]

Okay, da ja bisher keiner irgendwie einen Lösungsansatz zu haben scheint, schreibe ich mal, wie ich mich so langsam an die lösung des problems rantaste..
Zunächst habe ich von meiner kaputten platte ein winziges backup gemacht (ein drittel der platte wurde gebackupt, für mehr reichte der platz nicht aus, war ja nur zu testzwecken)

Code: Alles auswählen

dd bs=4k if=/dev/hda6 of=/mnt/extra/kopie_hda6

Da dieses Backup alle eigenschaften eines ext2 systems aufwies, ich aber die daten auf ein reiserfs gespielt habe, wurde das backup ohne Formatierung zu reiserfs umgewandelt:

Code: Alles auswählen

 mkfs.reiserfs -f /mnt/extra/kopie_hda6 

danach habe ich reiserfsck angewiesen, bei dem backup die verzeichnisstrukturen wiederherzustellen.

Code: Alles auswählen

reiserfsck --rebuild-tree --scan-whole-partition     /mnt/extra/kopie_hda6 

Und siehe da: meine Dateien waren sichtbar. Zwar nur in der Form

Code: Alles auswählen

rebuild_semantic_pass: The entry [3265 3325] ("Grifftabelle.pdf") in directory [2 3265] points to nowhere - is removed

, aber ich denke das liegt daran, dass die eigentlichen dateien weiter hinten auf der echten partition liegen, und somit bei meinem teilbackup einfach nicht draufgespielt sind.
Ein Einhängen über loop gibt mir zugriff auf das system:

Code: Alles auswählen

 mount -o loop /mnt/extra/kopie_hda6 /mnt/hda6 

, und wie nach einigem googlen zu erwarten, war der ordner "lost+found" voller unterordner mit kryptischen bezeichnungen (reiserfsck kann leider nicht die ordnernamen wiederherstellen), aber meine dateien waren nicht darin.
Es bleibt also spannend: Onkel Google's resultate weisen mich in allen möglichen rottönen darauf hin, dass man reiserfsck NIE ohne backup nutzen sollte, ich werde also erstmal nach ner gescheiten backupmöglichkeit für 30 GB suchen müssen ehe ich weiterarbeite.

###[ Update ]######
Nach dem Backuppen von 20 der 30 GB funktionierte oben angegebene Lösung noch besser: ich habe viele dateien wiederhergestellt, aber es scheint als ob teile der alten ordnerstruktur entweder weg sind oder aber sich im allerhintersten berich der letzten 10 GB der patition befinden.

[ryal]

Gelöst: Oben genannte Schritte führen zum Erfolg. Die Dateien werden auf der Festplatte in "lost + found" abgelegt und durchnummeriert. Das gibt zwar ein ganz schönes chaos, aber immerhin sind die dateien da und nutzbar... War die wiederhergestellte datei ein verzeichnis, so ist dieses nummeriert und alle dateien darin haben den originaldateinamen.
Ich kann noch nicht sagen, ob alle Dateien wiederhergestellt wurden, aber die wichtigsten sind jedenfalls da, und das ist gut so.

Woher der eigentliche Fehler genau kam, kann ich immernoch nicht nachvollziehen, aber ich werde nicht mehr qtparted nutzen...

[peschmae]

Bei mir hat auch mal QtParted die Partitionstabelle kaputtgemacht. Nutze ich auch nicht mehr

Und dabei habe ich nur eine Partition gelöscht...

MfG Peschmä