Nedávno jsem někomu amatérsky zachraňoval omylem přeformátovaný disk (Windows only, Linux v tom prsty neměl) - na disku byly dva začátky oddílu na dvou různých offsetech
Toto ma celkom zaujima, ako ste zistili ze tomu tak je?
Nepamatuju si podrobnosti, bylo to cca v září 2019 a co mám asi stránku zápisků, týkají se vlastně jenom recenze těch wokenních recovery softů.
Určitě jsem začal DDčkem na druhý disk stejný nebo větší. Zmrvené disky byly dva, 3TB a 4TB. Náhradní jsem měl 4TB.
Protože je to nad 2 TB, nestačila mi historická znalost BIOS partition table, ale musel jsem si nepatrně osvěžit vědomosti ohledně GPT. Rozhodně byla v MBR obvyklá "falešná/předsunutá/držhubná" partition table, která obsahuje jenom odkaz na GPT - ta je o kus dál. A je možné, že jsem měl na disku dvě verze už GPT. Nehrabal jsem se v tom kdovíjak do hloubky rukama, používám čerstvé verze linuxových "variant fdisku", z nichž značná část už GPT umí. Pochopitelně z MBR vede odkaz jenom na tu "nově vytvořenou GPT". Je možné, že jsem druhou/starou GPT ani nezkoumal. Ono na ní ostatně moc nezáleží, na celém disku byl vždycky jenom jeden oddíl - a kýžená informace je začátek NTFS oddílu (boot sektor), který se dá najít i přímo, možná snáz než GPT. Tuším bajt 3-6 (počítáno od nuly) obsahují řetězec "NTFS" a v posledních dvou bajtech ultra-klasicky 55AA hexa. Myslím že jsem zašel tak daleko, že jsem si zkusmo zkopíroval prvních pár megabajtů diskového prostoru DDčkem do image souboru a zkoušel jsem do toho koukat hexaeditorem, nejdostupnější je asi ten v Midnight Commanderu, umí vyhledat hexa sekvenci. No a tím ruční práce asi zhruba skončila - našel jsem dva různé boot sektory, zvedl jsem ruce z klávesnice a zabručel jsem "tak pozor".
Následoval zmíněný průzkum trhu recovery toolů (trial verzí), už v režimu "klikající cvičená opice". A už netuším jestli všechny, ale určitě EaseUS mi rovnou řekl, že tam vidí dva různé začátky oddílů, a dokonce vyrobil dva různé seznamy nalezených souborů (které měly společnou podmnožinu, jak se později ukázalo). Takže než klepnete na "restore", musíte si vybrat, podle kterého z těch dvou seznamů se pojede.
Mimochodem... @Martin Dráb, jste si jistej, že NTFS má dvě kopie Boot Sektoru? Mám pocit, že Boot sektor je jenom jeden, jsou dvě kopie MFT - primární a náhradní, umístěné kdesi v prostoru oddílu. NTFS používá stromovou strukturu metadat, rozptýlenou po ploše oddílu - podobně jako UNIXové FS. MFT je IMO jakási analogie EXT2/3/4 "superblocku" (ten se ukládá tuším dokonce v několika kopiích). FAT FS si vede dvě kopie FAT, uložené těsně za sebou hned za boot sektorem... (což není náš případ).
Já jsem ty svoje dvě verze NTFS bootsektoru našel v prvních pár megabajtech. Ony totiž existují různé konvence, jak zarovnat oddíly na geometrii disku (tzn. kolik prostoru před prvním oddílem vyplýtvat zarovnáním). Třeba klasický legacy BIOS styl s bootsektorem prvního oddílu na LBA sektoru č.63, typicky s LBA sektorem o velikosti 512B (nultá stopa zůstane kromě MBR prázdná) vs. zarovnání na nějaké "binárně kulaté číslo", typicky s LBA sektorem o velikosti 4 kB na moderních discích a flashkách - čímž se promrhá třeba první megabajt. Ale ono těch konvencí je zřejmě víc, moderní OS a třeba i různé verze Windows používají různé zarovnání i v rámci kategorie "4kB sektory a binárně hezká geometrie", matně si něco vybavuju o existenci "vycpávkového oddílu" v GPT před prvním vlastním datovým oddílem apod.
Vlastník těch nabořených disků dokonce tvrdí, že jednoho dne přišel ráno do práce, a Win10 se po aktualizaci po rebootu spontánně rozhodly, že externí disky v USB kastlíku zformátují s novým rozložením partišen... čemuž jsem ochoten věřit jenom s určitou mírou pravděpodobnosti, menší než stoprocentní :-) Taky už jsem dřív zažil případ, že človíček vzal disky, které do té doby používal jednotlivě v jednoduchém USB šuplíku, a vrazil je do levného RAIDového boxu pro dva disky, a představoval si, že ty disky uvidí tak jako dřív... a RAIDový box na tom vyrobil mirror a posunul začátek prezentovaný Windowsům a průser byl na světě... tehdy stačilo na discích odhadem vyrobit novou GPT, která odpovídala původní skutečnosti. Tentokrát jsem takové štěstí neměl.
Než jsem to provedl naostro, zkoumal jsem trial verze softů Recuva, EaseUS a GetDataBack - schopnostmi na celé čáře vyhrál EaseUS, druhý co do úspěšnosti byl teoreticky GetDataBack (ale ještě pomalejší než Recuva, která byla na 3-4TB disku ohavně pomalá). EaseUS byl nejschopnější a nejrychlejší.
Mozete prosim povedat blizsie o ake verzie islo? Od EaseUS som zatial skusil Partition Recovery Trial - A ten nedokaze pracovat s image. Jedina moznost by bola ako pisete zapisat data na iny disk. Ked som pustil nad spominanym diskom analyzu cez tento software tak sice trvala par minut ale bez nejakeho pouzitelneho vysledku.
V zápiscích čtu Recuva 1.53, EasUS 12.9.1, GetDataBack nemám napsané číslo verze. Každopádně všechny byly čerstvé v září 2019.
Měl jsem dva nabořené disky, a tuším ke každému dva náhradní, tzn. celkem čtyři náhradní. Po dohodě s vlastníkem, který věděl předem, že ty disky beztak obratem užije na větší objem úložiště. V prvním kroku jsem zkopíroval celý nabořený disk na první záložní. V druhém kroku EaseUS prohlásil, že zásadně nedělá in-place recovery, ale že je ochoten zachráněné soubory nakopírovat "někam jinam", asi by se dalo i na fileserver apod. Takže prostě dostal další disk, zformátovaný na NTFS :-)
Tyhle tooly mají většinou konfigurovatelnou "úroveň důkladnosti", a v defaultním nastavení víceméně projdou souborový systém od boot sektoru přes MFT a přeživší adresářovou strukturu, snad se snaží v těch metadatech něco hledat. Vy ale chcete zkusit hloubkový sken = úplně se vykašlat na stávající rozdělení disku a to co je na něm normálním způsobem vidět, a namísto toho hledat heuristicky po ploše disků poztrácené sekvence bloků. Je potřeba to v konfiguraci recovery toolu explicitně povolit. (Teď si nejsem jistý, jestli toto platí o EaseUS.) Hloubkový sken rozhodně netrvá pár minut - na 3TB disku trval v EaseUS cca "přes noc" (7 hodin), Recuva 20 hodin (a našla toho mnohem míň) a GetDataBack jel zpočátku snad ještě pomaleji než Recuva, ale nakonec dojel taky cca za 20 hodin. EaseUS točí diskem pořád. Ostatní dva většinu času nad něčím dumají a disk se fláká (občas mrkne). Přečíst celý disk sekvenčně od A do Z prostě trvá pár hodin. Pokud byl EaseUS během pár minut hotov, tak podle mého nemohl projít plochu disku "hloubkovým" způsobem.
EaseUS když skenuje, hlásí "nesmyslně" vysoký počet nalezených souborů. V mém případě zřejmě dva různé "náhledy" (protože dvě různé partišny) s velkým vzájemným překryvem, navíc zřejmě dost "crosslinkovaných" různě starých verzí souborů... prostě těsně před koncem skenu hlásil na 3TB disku průběžný stav 11.5 TB nalezených dat! Ovšem při obnově to zřejmě protřídí a velký počet "duchů" vynechá, ve finále obnovil asi 2.5 TB dat a vlastník tvrdil, že mu nejspíš nic nechybí. Nějaké crosslinkované soubory naházel bokem do adresáře viditelně označeného jako "další nalezené soubory a složky" - tyto jsou z větší části poškozené, ale jedná se zjevně o přízraky = starší a částečně přepsané verze jiných, úspěšně obnovených souborů.
Pokud skutečně EaseUS při hloubkovém skenu nic moc nenajde, může to mít různé příčiny: na Vaše formáty souborů nemá EaseUS vhodnou skenovací heuristiku (znalost), nebo jste nabořenému souborovému systému dále ublížil unáhleným použitím programu chkdsk, který opravuje metadata filesystému do konzistentního stavu tím způsobem, že uřízne a zahodí to, co mu nedává smysl... na tomhle serveru zřejmě dost lidí chápe pojem "fscked" :-) Věřím tomu, že hloubkový analyzátor by z poškozeného filesystému před chkdiskem vytěžil o něco víc.
Trial EaseUS je ochoten provést kompletní sken = i ten trial Vám dá poměrně přesnou představu, kolik se toho z disku dá zachránit. Dokonce se dá výsledek toho skenu ("mezistav obnovy") uložit na disk a později načíst. Trial ale obnoví jenom asi 2 GB dat. V mém případě si vlastník dat koupil licenci, a pak úspěšně proběhla kompletní obnova.
Recuva a CCleaner jsou podle mého dva různé softwarové produkty firmy Piriform, kterou v roce 2017 koupil Avast. Recuva na mě v září působila dojmem, že Avast dává zelenou spíš CCleaneru a Recuva chřadne. Ale mohlo se mezitím něco změnit, a můžu mít úsudek pomýlený konkrétním formátem datových souborů v mém případě = jedno pozorování není zrovna hodnotná statistika.
Ty hlášky v dmesg vypadají dost hrůzostrašně, přesto se nejedná o jasnou "media failure". Možná bych zkusil zkontrolovat/vyměnit SATA kabel.
Mozem sa opytat co by vyzeralo viac hrozostrasne? a o com tieto hlasky vlastne hovoria? Chapem ze topicaci sa slamky chyta, ale ma zmysel menit sata kabel ked ddrescue skopiroval disk na 99%?
...no je fakt, že já mám z dob svého mládí zafixované hlášky z linuxového IDE subsystému, jako "DriveReady SeekComplete Errror", což je ještě dost obecná chyba, ale bývala následovaná konkrétnějším kódem chyby.
Ty Vaše chybové hlášky se sypou ze SCSI vrstvy - kteroužto abstrakci už drahně let používá Linux a jeho moderní libata. Každopádně ta hláška nezní jako "sector not found" nebo "uncorrected error".
A máte pravdu, že nezní ani jako "CRC error" - kterážto chyba by poukazovala na nějaký analogový vakl v SATA data kabelu nebo konektory nebo HBA řadičem.
Ve Vašem případě "Illegal Request" a "Invalid field in CDB" (nedoprovázeno CRC errory, tzn. kontrolní součty na SATA/SCSI příkazech sedí) spíš vypadají, že ta chyba v CDB přišla od HBA a že vakl v datovém kabelu za to nemůže.
Našel jsem k této chybě zajímavou debatu na
StackExchange = mohlo by to znamenat bug spojený s konkrétní značkou čipu SATA řadiče v Linuxu...
Hardware error / internal target failure vypadá o něco závažněji, ale ten popis závady není zrovna specifický. SCSI Target = koncové zařízení = disk nebo RAIDový řadič apod.
15 Odpovědí
3352 Zhlédnutí