Sérült partíciós tábla helyreállítása

Merevlemezek, vezérlők

Kaptam egy ismerősömtől egy 500G külső winchestert, hogy sajnos ha rádugja a win-re azt írja, hogy formázza a lemezt. No mondom az nem jó dolog...
A jó az, hogy mivel én tartom rendben a dolgait van egy nem túl régi backup máshol is. De azért szeretnék próbálkozni, hátha sikerülne valamit alkotni.

Figyelmeztetés:
ntfs_mst_post_read_fixup_warn: magic: 0x44414142 size: 1024 usa_ofs: 40 usa_count: 8: Érvénytelen argumentum
Record 0 has no FILE magic (0x44414142)
Failed to load $MFT: Kimeneti/bemeneti hiba
Failed to mount '/dev/sdb1': Kimeneti/bemeneti hiba
NTFS is inconsistent. Run chkdsk /f on Windows then reboot it TWICE!
The usage of the /f parameter is very IMPORTANT! No modification was
made to NTFS by this software.

Próbáltam futtatni a chkdsk /f és /r és mindkét kapcsolóval, sajnos sikertelenül.
Van valakinek ötlete NTFS MFT helyreállítására?

  • 10525 megtekintés

Félek, okoskodás lesz, amit írok, de azt gondolom, ha odaveszett a filerendszer adminisztrációja, az ilyen recovery programok megtalálhatják a file elejét, de a helyreállítás azzal a feltételezéssel sikerülhet, hogy a file allokált szektorai egymást követik, azaz nem volt a file fragmentálódva. Viszont, ha töredezett a file, az előbbi feltételezéssel nem a saját darabkái kerülnek „visszamentésre”, így aztán az eredmény nem lesz éppen kielégítő.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Majdnem igazad van... Szerintem... :)
Elméletileg az NTFS-nek vannak tartalék MFT-i... és ezek pontosan nem egy helyen vannak... pont azért, hogy ha mondjuk a diszk eleje sérül, akkor még lehessen menteni róla...

Ha a fájlnevek megvannak, akkor szerintem van egy MFT is... Hogy ez mennyire régi, az jó kérdés...
Valószínű, hogy a kérdőjelek miatt nem eléggé új. :(
--
Debian Linux rulez... :D

Ez miért érdekes? Software-es oka is lehetett annak, hogy a filerendszer leírói sérültek, vagy más, HDD-n kívüli hardware probléma, például CPU és memória közötti kommunikáció hibája. Akár az is, ha valaki specifikáción kívül, magasabb órajel frekvenciáról járatta a CPU-t, esetleg a memóriát.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( th v | 2015. 09. 30., sze – 09:39 )

létezik ntfsfix is, nem tudom mennyire hatékony...
--
TH

( uid_20269 | 2015. 09. 30., sze – 09:43 )

testdisk.?
--
God bless you, Captain Hindsight..

( Frantique v | 2015. 09. 30., sze – 09:51 )

Az árulkodó sor:

Failed to load $MFT: Kimeneti/bemeneti hiba, ez sajnos nagyobb probléma, mint egy szétesett MFT.

Amit tehetsz: klónozd a lemezt dd-vel (igen, dd, és nem dd_rescue!!!), használd a conv=noerror,sync kapcsolókat, majd a képfájlt másold, és a másolaton kezdj el kísérletezni. Testdisk esélyes lehet, sőt, először egy force mountot azért kipróbálnék, láttam már így elérhetővé váló particiót.

--
Coding for fun. ;)

Tapasztalat szerint a dd_rescue nem annyira toleráns, sokszor évekig tartana ekkora adatmennyiséget leklónozni vele, ha sérült a HDD. Természetesen az elvesztett adatmennyiség a lehető legkisebb (addig bontja a szektorokat kisebb részekre, ameddig csak bírja), azonban általában elenyésző a sérült szektor, ezért inkább a dd a fent említett paraméterrel célravezetőbb és gyorsabb. Ezért mondtam, hogy inkább dd legyen a másolóeszköz. (Ha mégsincs I/O hiba, akkor irreleváns, ugye.)
--
Coding for fun. ;)

Nem akartam beleszólni, mert nem volt szükségem tapasztalatok gyűjtésére, de szerintem éppen a sima dd az, amelyik i/o error esetében kilép hibával, és ennyi, a dd_rescue pedig paraméterezhető módon reagál, kísérletezik, kihagyja a szektor olvasását, vagy kihagyja, a cél helyére nullákat ír, vagy akármi, de mindenképp lesz egy legjobb kimeneti file.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A dd alapesetben tényleg kilép, ezért kell a kapcsolókat használni, amiket írtam. Sok-sok benchmark adatom gyűlt az évek során, nem ok nélkül javasoltam első körösre a dd-t. Például nemrég volt egy 1 TB-os lemez, pár darab szétszórt I/O hibás résszel, a dd_rescue (és a ddrescue is, mindkettőt megnézve), 1x-es újraolvasási kísérlet mellett 16 byte / sec sebességet produkáltak valamiért, számold ki, mennyi ideig tartott volna, a dd pedig egy nap alatt lehúzott egy másolatot, elvesztettem összesen 1,5 MB-ot, amit felsyncelt, így valós adatvesztés nem is lett (szerencsére a hasznos adatokat nem érintette).
--
Coding for fun. ;)

( gazsiazasz | 2015. 09. 30., sze – 16:12 )

És kéccer újra is indítottad utána, ahogy írja ott fenn?
NTFS-hez a chkdsk a hivatalos recovery tool. Ha az nem működik, akkor max testdisk-kel ki tudod menteni róla a fájlokat. Remélhetőleg. Amúgy backup és nincs ilyen szopás.

( locsemege v | 2015. 10. 01., cs – 11:22 )

Miért sérült partíciós tábláról szól a cím akkor, amikor a filerendszer sérült?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( cilimpo | 2015. 10. 04., v – 16:26 )

AOMEI Partition Manager windows alatt

( aga_et v | 2015. 10. 07., sze – 10:28 )

Ugyan nekem egy 16 gigás microsd-hez kell ez a művelet amin fat van, de lehet, hogy jó jesz. Legalább itt nem csak win only módszerek vannak.
☼☆♫♪♫♪☆☼
AGA@
Fork portal és az egyik logóm :)