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

 ( zslaszlo | 2015. szeptember 30., szerda - 8:31 )

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?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

R-Studio? (http://www.r-studio.com/)

--
Debian Linux rulez... :D

Ez megtalálta az összes fájlt. Jelenleg a demo verzióval dolgozom. A talált dokumentumok azonban krikszkrakszok lesznek a recover után. Ez annyit tesz, hogy búcsút lehet mondani az adatoknak?

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

Igen, sajnos erről lehet szó. Pedig minden fájlt megtalált. Csak épp helyreállítani nem tudja. De eddig ez az egyetlen program, ami egyáltalán fel tudta deríteni a fájlrendszert. Érdekles módon a felületi szkennelés azt mutatja, hogy ép a lemezfelület...

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

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

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

+1

+1


DigitalOcean 10$ kredit- Cloudatcost VPS 50%: MEQy2epUny - <3 openSUSE, Ubuntu, KDE <3

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. ;)

Miért nem a dd_rescue? Nem kötekedésből, tényleg, csak a dd helyett szokták javasolni, hogy.

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. ;)

Áh, így már értem, köszi.

vannak az ujraolvasast szabalyozo kapcsoloi (--max-retries, --timeout, --no-split), azokat probaltad?

esetleg vegig lehet menni a diszken/cd-n eloszor ujraolvasas nelkul, aztan nyuzva.

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

alapbol tenyleg, de talan a conv=sync,noerror ezt megoldja.

Most ránéztem a dd manjára, és úgy tűnik, tényleg. Ezt mindig is tudta, vagy az utóbbi években került bele?


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

hat, ezt nem tudom. remlett, hogy tudja ezt a dd, de azert meg kellett neznem a man-t.. :)

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. ;)

É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.

Igen újraindítottam. Testdisk futott, sajna nem sikerült helyreraknia. Amúgy van egy régebbi backup, tehát csak próbálkozom, hátha sikerül. De nem olyan fontos...

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

Lehet hogy a fájlrendszer ép, csak a partíciós tábla rossz. Persze nyilván nem erről van szó, de kb. lényegtelen is.

Arra gondolsz, hogy nem a filerendszer elejére mutat?


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

Jaja. A hibaüzenetből ugyan én meg nem mondom hogy ez most egy csak kicsit karcos MFT vagy akár fehér zaj is lehet. Viszont a partíciós tábla könnyen ellenőrizhető, ha nagyon idióta helyekre mutat, akkor akár az is lehet hogy tényleg az kapott fényt.

AOMEI Partition Manager windows alatt

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 :)