Datenrettung nach fdisk und mkfs möglich?

    Hallo, sorry für diese Frage, aber mir ist so ziemlich das blödeste passiert, was einem passieren kann. Über die Suche habe ich leider nichts entsprechendes gefunden.


    Habe eine 3. Platte in den VDR eingebaut und habe nicht gemerkt, dass die zweite Platte nicht mehr /dev/sdb, sondern /dev/sdc hieß. Jedenfalls hatte ich geglaubt, dass die neue 3. Platte /dev/sdc heißt und habe munter darauf fdisk losgelassen und eine Partition angelegt, und danach noch mkds /dev/sdc -t ext3. Dabei habe ich aber meine alte 2. Platte überschrieben. Peinlich, peinlich.


    Frage: ist da noch was zu retten, und wenn ja, wie? Es sind viele für mich wichtige Aufnahmen drauf. Bevor ich hier Panik bekomme, habe ich die betroffene Platte erstmal abgeklemmt. Ich hoffe mal stark, dass die Platte nicht komplett überschrieben wurde und dass da die Infos noch irgendwo sind.


    Ach ja, tut mir leid, wenn das schon öfter gefragt wurde, habe aber über die Suche nichts gefunden. Ich würde mich total freuen, wenn mir jemand weiterhelfen kann. Mir würden schon entsprechende Links im Netz weiterhelfen.


    Danke und gute Nacht!

    Mein VDR: yavdr 0.5, Mystique SaTiX-S2, GA-P43-ES3G

    2 Mal editiert, zuletzt von Kosmas ()

    fdisk alleine wäre nicht so schlimm gewesen, aber ein mkfs wenn es das gleiche FS war schon. Dann werden nämlich alle Kopien der Superblöcke ebenfalls überschrieben, das Medium ist ja gleich groß.
    Wenn Du vorher ein anderes Dateisystem hattest als Du jetzt mit mkfs formatiert hast, dann ist evtl noch etwas zu machen...

    Tja, vorher war es ext3, und das ist es jetzt auch wieder. Die Daten werden aber nicht komplett überschrieben? Das hätte wohl auch etwas länger gedauert. Theoretisch müsste man die Sektoren auslesen können, die Frage ist nur, wie man das wieder in gültige Dateien zusammensetzt.


    Werde mich mal umsehen, ob es da Software gibt.

    Mein VDR: yavdr 0.5, Mystique SaTiX-S2, GA-P43-ES3G

    Einmal editiert, zuletzt von Kosmas ()

    Hi kosmas,
    mir ist auch schonmal vor längerer Zeit dieser Fehler unterlaufen.
    Mir ist es damals gelungen den größten Teil der alten Aufnahmen wiederherzustellen!
    Dazu habe ich damals mit Testdisk die alte Partitionsstruktur wiederhergestellt und anschließend mit fsck das Dateisystem repariert.
    Da fsck nicht automatisch durchlief, sondern immer fragte ob er irgendwelche Blöcke wiederherstellen soll, musste ich hunderte Mal diese Frage mit OK (oder auch Y, weiß ich jetzt nicht mehr genau) bestätigen.
    Am Ende hatte es sich aber gelohnt, da mindestens 90% der Aufnahmen wiederhergestellt waren. 8)


    Einen Versuch wäre es wert.


    Paulaner

    Danke für die Infos. Ich werde es zuerstmal mit testdisk probieren. Allerdings scheint Razorblade da eher pessimistisch zu sein. Das Ergebnis werde ich natürlich posten.


    Paulaner, konnte testdisk auch die Namen der Verzeichnisse und Dateien rekonstruieren? Und hatte der Erfolg etwas damit zu tun, ob die Daten fragmentiert waren?


    Bevor ich was mache, werde ich die Platte komplett spiegeln. Da die Platte physikalisch OK ist, dürfte das mit dd gehen. Ich muss nur darauf achten, nicht die leere auf die alte zu kopieren. Gibt es einen Tip, wie ich zwei identische Festplatten voneinander unterscheiden kann? Beide sind ja leer, nur die eine enthält ein scheinbares leeres Dateisystem.


    Wieso ändern sich eigentlich die Devicenamen der Platten beim Einbau einer weiteren Platte? Damit funktioniert u.a. das mounten durch fstab nicht mehr, wie ich (zu spät) in den logfiles sehen konnte.

    einzeln reinhängen und die UUID auslesen. Mit dieser klappt dann auch das richtige mounten in der fstab. Hab ich alles bei meinem Server gemacht...

    HD: yaVDR 0.3, AT3IONT-I, CINE2S, NVRAM, X10, 2.5´ 320GHDD
    SD: ctvdr 7 vdr 1.6.0, MSI 6318 (Medion2000), 667MHz, NVRRAM, WOL 500G HD
    TV: Sharp LC52XL2E (100Hz), Beamer: Sanyo Z5

    Zitat

    Original von Paulaner
    Da fsck nicht automatisch durchlief, sondern immer fragte ob er irgendwelche Blöcke wiederherstellen soll, musste ich hunderte Mal diese Frage mit OK (oder auch Y, weiß ich jetzt nicht mehr genau) bestätigen.Paulaner


    auch mit der Option " -p " ?


    Gruß Fr@nk

    Hi,


    wie Razorblade schon schrieb, kann ein mkfs.ext3 an dieser Stelle verhängnisvoll sein, da das Dateisystem auf die jounal-informationen aus den Superblocks bzw. Inode-Blocks angewiesen ist. Die Daten nur aus den (noch intakten) Datenblocks wiederherstellen zu können ist eher unwahrscheinlich, das geht eigentlich nur noch wenn einige große Dateien im Dateisystem angelegt worden sind und der Fragmentierungsgrad entsprechend niedrig ist. Bei einem VDR, wo laufend Aufnahmen angelegt und dann wieder geloscht werden, ist es - denke ich - eher unwahrscheinlich. Schau' Dir auch mal das Tool ext3grep an, da gibt es auch jede Menge Hintergrundinformationen, wie dieses Dateisystem funktioniert.




    Zitat

    Original von Kosmas
    Gibt es einen Tip, wie ich zwei identische Festplatten voneinander unterscheiden kann?


    Dafür kann man UDEV-Regeln verwenden. Z. B. kann UDEV anhand der UUID/Serial/etc. einer Platte einen symbolischen link in der Art:

    Code
    /dev/Platte1 --> /dev/sdc1
/dev/Platte2 --> /dev/sda1
/dev/Platte3 --> /dev/sdb1

    anlegen. Hier mal ein Beispiel aus einer meiner rules unter /etc/udev/ruled.d/z98-cryptsetup.rules:

    Code
    ACTION=="add", BUS=="usb", KERNEL=="sd?1", SYSFS{idVendor}=="152d", SYSFS{idProduct}=="2329", SYSFS{serial}=="00000000xxxx", SYMLINK+="fusi1", RUN+="/bin/bash -c '/etc/udev/scripts/automount.sh start fusi1 & >/dev/null </dev/null 2>&1'"


    Zur Erklärung: es handelt sich um eine USB-Festplatte (BUS=="usb") mit einer Partition (KERNEL=="sd?1"). Es wird nach Vendor- und Product-ID geschaut (in meinem Fall ein Fujitsu-Siemens Storagebird), sowie Serial, und dann wird auf diese Platte ein Symlink unter /dev/fusi1 angelegt. Weil meine Platte dann noch verschlüsselt ist, wird für den besseren Komfort noch ein Skript zum automatischen entschlüsseln aufgerufen (/etc/udev/scripts/automount.sh) aufgerufen.


    Grüße joker

    HW VDR: Thermaltake DH102 | Gigabyte GA-M720-US3 | AMD 270u | 8GB RAM | 120GB SSD System + 3TB HDD Daten | L4M Cine CT V6 + Flex S2 | Zotac GT630 | Futaba MDM166A | Atric IR-Einschalter Rev. 5 | NEC P553 | SEDU + 96 PIX | Pioneer SC-LX85 | Jamo S606
    SW VDR: Debian Wheezy | Kernel 3.2.0-4-amd64 | Mate 1.6 | VDR 2.2.0 | nVidia 331.79 | LIRC 0.9.0 | media_build_experimental | Plugins: permashift 1.0.3, softhddevice 0.6.1rc1-git, menuorg 0.5.1, skinnopacity 0.1.3, tvscraper 0.2.0-git, seduatmo 0.0.2-git, mplayer 0.10.2-hg, fritzbox 1.5.3, vdradmin-am 3.6.9, femon 1.7.19, targavfd 0.3.0, span 0.0.7, dvd 0.3.6-cvs, graphtftng 0.4.10-git, extrecmenu 1.2.4-git, epgsearch 1.0.1-git, block 0.1.2-git, cpumon 0.0.6a, ac3mode 0.1, HD-- 1.0.0-hg, u. v. a. ...

    Zitat

    Original von videoman
    einzeln reinhängen und die UUID auslesen. Mit dieser klappt dann auch das richtige mounten in der fstab. Hab ich alles bei meinem Server gemacht...


    mit fstab funtioniert's natürlich auch.

    HW VDR: Thermaltake DH102 | Gigabyte GA-M720-US3 | AMD 270u | 8GB RAM | 120GB SSD System + 3TB HDD Daten | L4M Cine CT V6 + Flex S2 | Zotac GT630 | Futaba MDM166A | Atric IR-Einschalter Rev. 5 | NEC P553 | SEDU + 96 PIX | Pioneer SC-LX85 | Jamo S606
    SW VDR: Debian Wheezy | Kernel 3.2.0-4-amd64 | Mate 1.6 | VDR 2.2.0 | nVidia 331.79 | LIRC 0.9.0 | media_build_experimental | Plugins: permashift 1.0.3, softhddevice 0.6.1rc1-git, menuorg 0.5.1, skinnopacity 0.1.3, tvscraper 0.2.0-git, seduatmo 0.0.2-git, mplayer 0.10.2-hg, fritzbox 1.5.3, vdradmin-am 3.6.9, femon 1.7.19, targavfd 0.3.0, span 0.0.7, dvd 0.3.6-cvs, graphtftng 0.4.10-git, extrecmenu 1.2.4-git, epgsearch 1.0.1-git, block 0.1.2-git, cpumon 0.0.6a, ac3mode 0.1, HD-- 1.0.0-hg, u. v. a. ...

    Hallo joker,


    Zitat

    Original von joker4791
    Die Daten nur aus den (noch intakten) Datenblocks wiederherstellen zu können ist eher unwahrscheinlich, das geht eigentlich nur noch wenn einige große Dateien im Dateisystem angelegt worden sind und der Fragmentierungsgrad entsprechend niedrig ist.


    Dann habe ich ja gute Chancen, da die betroffene Platte nur als Archiv diente, auf die ich einige VDR-Dateien kopiert hatte. Der VDR selbst hat darauf nicht gespeichert, ich konnte nur von der Platte abspielen.


    Leider dauert das Kopieren mit dd sehr lange, es sind nur 19,2 MB/s (trotz Sata intern). Bei 1,5 TB kommen da einige Stunden zusammen. Morgen weiß ich hoffentlich mehr!


    Nach dem ext3grep schaue ich gleich auch mal. Meinst Du, testdisk hat in meinem Fall gar keinen Sinn?


    Grüße, Kosmas

    Hi,


    Zitat

    Original von Kosmas
    Meinst Du, testdisk hat in meinem Fall gar keinen Sinn?


    Ein Versuch kann ja nicht Schaden ;) .


    Wie Razorblade schon schrieb, würde ich erstmal mit foremost anfangen. Das ist auch dafür geeignet, MPEG-Dateien wiederherzustellen.


    Grüße joker

    HW VDR: Thermaltake DH102 | Gigabyte GA-M720-US3 | AMD 270u | 8GB RAM | 120GB SSD System + 3TB HDD Daten | L4M Cine CT V6 + Flex S2 | Zotac GT630 | Futaba MDM166A | Atric IR-Einschalter Rev. 5 | NEC P553 | SEDU + 96 PIX | Pioneer SC-LX85 | Jamo S606
    SW VDR: Debian Wheezy | Kernel 3.2.0-4-amd64 | Mate 1.6 | VDR 2.2.0 | nVidia 331.79 | LIRC 0.9.0 | media_build_experimental | Plugins: permashift 1.0.3, softhddevice 0.6.1rc1-git, menuorg 0.5.1, skinnopacity 0.1.3, tvscraper 0.2.0-git, seduatmo 0.0.2-git, mplayer 0.10.2-hg, fritzbox 1.5.3, vdradmin-am 3.6.9, femon 1.7.19, targavfd 0.3.0, span 0.0.7, dvd 0.3.6-cvs, graphtftng 0.4.10-git, extrecmenu 1.2.4-git, epgsearch 1.0.1-git, block 0.1.2-git, cpumon 0.0.6a, ac3mode 0.1, HD-- 1.0.0-hg, u. v. a. ...

    Zitat

    Original von Kosmas
    ...
    Leider dauert das Kopieren mit dd sehr lange, es sind nur 19,2 MB/s (trotz Sata intern). Bei 1,5 TB kommen da einige Stunden zusammen. Morgen weiß ich hoffentlich mehr!
    ...
    Grüße, Kosmas


    Hast du bei 'dd' auch den Parameter 'bs=64M' mit angegeben? Sonst liest und speichert der nur Sektorenweise; und das dauert eeeeeeewig...


    PS: ein 'kill -SIGUSR1 $(pidof dd)' aus einer zweiten Shell sagt dir, wie weit 'dd' ist (Ausgabe im 'dd'-Window)

    Mit den smartmontools (smartctl -i /dev/sda) wird dir die Seriennumer ausgegeben. Diese mit der auf dem Aufkleber vergleichen.


    Leider passiert es mir auch immer wieder mal, dass sich die Laufwerke vertauschen. Dies scheint ein generelles Problem/Feature von Sata + USB Laufwerken zu sein...


    zum Kopieren würde ich übrigens ddrescue (nicht verwechseln mit dd_rescue) empfehlen. da aber keine badblocks drauf sein werden geht auch dd...


    Gruß
    Roland

    Software: VDR 1.4.3, mp3, osdpip, streamdev-server, femon, wapd, X11, Wireless Keyboard Kernel: 2.6.18
    Hardware: 1x DVB-S v 1.3, 1x Skystar 2, Celeron@2GHz, 256 MB RAM, 4 HDs Raid1/5, Total: 600 GB, Asus P4S533 cmi8738 & LAN on board 6 PCI
    40" Sammelbestellungs-LCD an ATI Radeon 9550 DVI-Out + tvtime, 70 cm TV an J2-RGB-Out
    Organisator der ersten und zweiten VDR-Sanitizer Sammelbestellung.
    In progress: POV-ION 330 - MediaPointer MP-S2 - vdr 1.7.9 - vdr-xine(vdpau)

    Einmal editiert, zuletzt von pram ()

    Hi,
    Beileid.
    Zum Kopieren nehme ich mittlerweile ddrescue (apt-get ins. gddrescue), das ist einfache als dd (habe ich zuvor Jahrelang benutzt) und zeigt den Fortschritt an.

    Grüße, Dieter :)

    Zitat

    Original von Razorblade
    In jedem Fall würde ich nur mit Images der Platte (zB mit dd) arbeiten um nicht bei Recovery-Versuchen noch mehr kaputt zumachen...


    Klar, dazu mache ich ja das Kopieren mit dd.

    Zitat

    Original von berndl
    Hast du bei 'dd' auch den Parameter 'bs=64M' mit angegeben? Sonst liest und speichert der nur Sektorenweise; und das dauert eeeeeeewig...


    PS: ein 'kill -SIGUSR1 $(pidof dd)' aus einer zweiten Shell sagt dir, wie weit 'dd' ist (Ausgabe im 'dd'-Window)


    Ja, nachdem meine erste Sitzung mit Putty unerwartet beendet wurde und der Kopiervorgang nicht fertig wurde, habe ich bei man dd nochmal genauer nachgelesen und einfach mal bs=64k ausprobiert. Dadurch war die Kopiergeschwindigkeit 109MB/s (ging dann aber gegen Ende auf 87MB/s zurück). Kann ja beim nächsten Mal 64M ausprobieren.


    Das mit dem -SIGUSR1 kannte ich schon. Hab dd mit "&" im Hintergrund gestartet, dann brauche ich auch kein zweites Terminal.


    Hab heute mittag testdisk gestartet. Das ist aber noch immer am analysieren (55%).


    Viele Grüße und vielen Dank für die Mithilfe.


    Kosmas

    Zitat

    Original von Paulaner
    mir ist auch schonmal vor längerer Zeit dieser Fehler unterlaufen.
    Mir ist es damals gelungen den größten Teil der alten Aufnahmen wiederherzustellen!
    Dazu habe ich damals mit Testdisk die alte Partitionsstruktur wiederhergestellt und anschließend mit fsck das Dateisystem repariert.
    Paulaner


    Leider hat das wie befürchtet gar nichts gebracht. Testdisk sucht nämlich nach partitionen, und selbst nach einem eintägigem deep scan findet es nur die leeren ext3-Einträge.


    Bin grade am testen, was mit foremost geht. Leider entsprechen die vdr-Aufnahmen nicht dem mpg-Standard, ich muss die config-Datei anpassen. Bisher bekomme ich nur defekte Fragmente heraus. Mal schauen, ob das noch etwas ans Licht bringt.


    Falls alle Stricke reißen, hab ich halt wieder eine leere neue Platte ;(


    Hat nicht zufällig jemand die Sendung mit der Maus archiviert? Falls ja, kann er sich gerne per pm oder mail an mich wenden.


    Viele Grüße, Kosmas

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden