EN

Zachraňujeme dáta zo zlyhávajúceho disku. Zn. zadarmo

Modelový prípad

Záchranu si ukážeme na disku môjho kamaráta, ktorému začal umierať rok starý 2TB disk (schválne neuvádzam model, až sa tu nestrhne flamewar :) ). Z celkovej kapacity bolo zabraných okolo 700GB, pričom drtivú väčšinu tvorili fotografie. Spočiatku sa na disku nedali prečítať niektoré súbory, nasledovali pády súborového systému, ktorý síce Windows pri štarte čiastočne opravil, no po ďalšom reštarte bol súborový systém opäť neprístupný. Z disku sa štandardným kopírovaním podarilo dostať iba 100GB dát.

Už len SMART výpis vyzeral nelichotivo, report môžte nájsť TU. Disk mal 48696 pending sektorov, jeho fitness je nulová. Nakoľko 2TB je pomerne veľká kapacita, disk som naklonoval na druhý, taktiež 2TB disk a kvôli log súboru bol ešte pripojený USB externý disk, ale pohodlne by stačil aj USB kľúč, log súbor má rádovo kilobajty. Plus teda USB kľúč, z ktorého nabootoval Linux. V systéme to teda vyzeralo nasledovne:

  • USB kľúč, z ktorého bootuje Rescue Remix
  • poškodený 2TB disk, identifikovaný ako /dev/sda
  • nový 2TB, na ktorý bude vytvorený klon, /dev/sdb
  • externý disk kvôli zápisu log súboru, /dev/sdc, pripojený ako /media/externy

A ideme do akcie:

1.

Ideálne na inom počítači si pripravte USB kľúč s Rescue Remixom. USB kľúč najprv naformátujte na FAT32. Stiahnite ISO Rescue Remixu a program UNetbootin. Spustite UNetbootin, vyberte ISO súbor a počkajte, kým nebude nahratý na USB kľúč.

2.

Pripravte si počítač, na ktorom budete zachraňovať dáta. Odpojte všetky disky, ktoré nepotrebujete, podstatný je len poškodený disk, cieľový disk, prípadne ešte tretí disk/druhý USB kľúč, kam budete ukladať log z ddrescue, nakoľko log nie je možné ukladať na USB kľúč, z ktorého bootujete (teoreticky je, ale museli by ste si vytvoriť perzistentnú Live USB inštaláciu). Pokiaľ budete vytvárať image a nie klon, môžete log uložiť aj na cieľový disk. Počítajte tiež s tým, že počítač, na ktorom pobeží záchrana, môže v závislosti na veľkosti zachraňovaného disku trvať niekoľko dní.

3.

Nabootujte z USB kľúča, bude Vás čakať terminál. V prvom rade musíme disky v systéme identifikovať. K tomu slúži utilita fdisk. Do terminálu napíšte:

sudo fdisk -l

 

 

 

a mali by ste vidieť výpis podobný tomuto:

(príklad výpisu utility fdisk na mojom notebooku. Výpisy pre jednotlivé disky sú odelené červenou čiarou, zelenou je zvýraznená adresa disku. Vidno dva 320GB disky, každý s 2 partíciami, 128GB SSD s 1 partíciou plus 16GB USB kľúč, z ktorého som nabootoval)

Zaujímajú nás riadky, kde sa uvádzajú cesty ako /dev/sda (ak chceme celý disk, tak bez čísla, ak partíciu, tak aj s číslom podľa zoznamu partícií na disku, napr. /dev/sda2). Disky môžete identifikovať napr. podľa kapacity či počtu partícií. Pokiaľ vytvárate image alebo používate 2 disky identickej veľkosti a rovnakým počtom partícií a neviete ich rozoznať, prejdite na bod 4, ináč skočte na päťku.

4.

Ak vyvárate image, musíte pripojiť filesystem cieľovej partície. Prípadne keď máte zdrojový aj cieľový disk rovnako veľký a neviete ich rozlíšiť, môžete u jedného z nich vyskúšať pripojiť jeho systém súborov. Urobíte to nasledovne:

  • najprv treba vytvoriť prípojný bod (priečinok), obvykle do priečinku /media:
    sudo mkdir /media/mojDisk

    kde mojDisk je meno priečinka, ktorý sa vytvorí, zvoľte aké chcete

  • následne pripojíme súborový systém partície príkazom mount, napr. takto (pripájame partíciu, nezabudnúť na číslo):
    sudo mount /dev/sdc1 /media/mojDisk

 

 

 

Pokiaľ operácia prebehne rýchlo, jedná sa pravdepodobne o fungujúci disk, kam chcete dáta zachrániť. Ak však ostane blikať kurzor rádovo minúty, je to zlyhávajúci disk, po pár minútach zrejme dostanete chybové hlásenie. Overiť to tiež môžete tak, že sa na obsah pripojeného disku pozriete, spustite:

mc

(súborový manažér Midnight Commander) a prejdite na miesto, kde ste vytvorili prípojný bod, v tomto príklade /media/mojDisk, a priečinok otvorte, podľa obsahu by ste to mali poznať.

5.

Pokiaľ poznáme cestky k diskom, môžeme pristúpiť k samotnej záchrane. V prvej fáze sa budeme snažiť zachrániť len dáta, ktoré je možné bez problémov prečítať. Ja som použil klonovanie, takže bolo treba pridať aj parameter --force, ktorým potvrdzujete, že obsah cieľového disku bude prepísaný. Väčšina príkazov musí bežať ako root, preto spúšťame cez sudo, heslo nie je vyžadované.

Štruktúra príkazu je ddrescue [-parametre] [zdroj] [cieľ] [log]. Log je síce nepovinný, ale pri záchrane tento parameter určite zadajte. Pokiaľ log súbor neexistuje, bude vytvorený.

Pre vytváranie klonu v prvej fáze vyzerá príkaz takto (cesty k diskom si nastavte podľa seba):

sudo ddrescue --no-split --force /dev/sda /dev/sdb /media/externy/log.txt

alebo ak vytvárate obraz, napr. takto:

sudo ddrescue --no-split /dev/sda /media/externy/image.img /media/externy/log.txt

U 2TB disku so skoro 50 tisíc chybnými sektormi trvala táto operácia 2 dni. Na záver vidíte vo výpise, koľko celkovo chybných dát na Vašom disku je. V tomto prípade  to bolo okolo 56MB, zvyšok sa podarilo prečítať.

6.

Niekomu môže stačiť záchrana toho, čo sa dalo prečítať a môže preskočiť na bod 7, no ja som sa z disku pokúsil dostať, čo to dá. V druhom prechode povieme ddrescue, nech sa snaží prečítať obsah chybných sektorov, zároveň vyradíme z prevádzky cache operačného systému, aby sme čítali dáta priamo z povrchu.

Pre klon:

sudo ddrescue --direct --force /dev/sda /dev/sdb /media/externy/log.txt

 

 

 

Pre image:

sudo ddrescue --direct /dev/sda /media/externy/image.img /media/externy/log.txt

Tu je práve dôležité mať log z predchádzajúceho kroku, nakoľko všetky korektne prečítané dáta budú preskočené, ddrescue sa bude zaoberať len chybnými sektormi. POZOR! V tomto konkrétnom prípade bežala operácia 13 DNÍ! Podarilo sa však znížiť množstvo chybných dát o 44 percent na 31MB. Pokiaľ na disku nemáte až tak dôležité dáta, môžete tento krok preskočiť.

7.

Máme vytvorený image/klon, je na čase ho opraviť. V prvom rade musíme vymazať údaje o chybných sektoroch, nakoľko na fungujúcom disku žiadne nemáme, no v tabuľke súborového systému zo zlyhaného disku sú. To isté platí pre image.

Klon:

sudo ntfsfix -b /dev/sdb

 

 

 

Image:

sudo ntfsfix -b /media/externy/image.img

 

 

 

8.

Môžme pristúpiť k oprave súborového systému. Môžte to nechať na Windows, ktorý pri štarte zistí, že sa jedná nekonzistentný disk a spustí CheckDisk, alebo to môžete urobiť priamo v Linuxe. Príkaz je rovnaký ako v kroku 7, akurát že vypustíte parameter -b.

9.

Ak ste robili image, môžete ho cez dd alebo ddrescue "napáliť" na nový disk podobným spôsobom:

sudo ddrescue --force /media/externy/image.img /dev/sda

 

 

 

Log už v tomto prípade nepotrebujete.

Komentáre (12)
Broslowski
Skvelý článok, tlieskam!
Shatterhand
Ja len takú malú poznámočku - termín "plávajúca báza" sa (pokiaľ viem) nepoužíva, používa sa termín "plávajúce hradlo", aj keď v zásade slovo gate/base možno preložiť ako báza/hradlo. Technicky to však nie je správne, pretože báza alias base sa používa len pri určitom type tranzistora(nebudem to rozpitvávať), pri inom zasa gate. Ale inak klobúk dole za článok, muselo to zabrať dosť času naštudovať a tak jasne spracovať !
periodic
Pomocou akeho programu sa da zistit access time na jednotlive sektory (staci iba pri citani), ale pritom sa dal nastavit timeout, pokial ten cas presiahne mnou nastavenu hodnotu? Pri programe Victoria 4.46 vsetko ide, len nereaguje na mnou nastaveny timeout cas a stale sa snazi citat sektory, ktore maju pristup vacsi, alebo su poskodene, ze ich nevie precitat. Taka detekcia potom trva zbytocne dlhu dobu a pritom aj tak nepotrebujem vediet aky je cas pokial je vecsi ako mnou nastavena hodnota (pre mna pouzitelny cas je do 100 ms, ale program sa stale snazi citat sektory aj s niekolko sekundovym pristupom). Chcel by som si zistit este neposkodene casti (obsadit ich particiou) a tie este na nejaky cas pouzivat, ostatne poskodene casti a casti s horsou dobou pristupu by zostali neobsadene (nepouzivane).
Pjetro_de
Dovolim si oponovat v tom, ze RAID je naplast a riesi svetko zalohovanie. Neriesi. Zachrana dat z pokazeneho RAID pola (nie jednotliveho pokazeneho disku, ale celeho RAID pola) je ovela zlozitejsia ako zachrana dat na jednotlivom disku. Ak totiz zlyha SW obsluhujuci RAID, na diskoch su/budu necitatelne nezmysly. Ak zlyha HW (radic RAID pola), asi na tom nebudeme o nic lespie, ba este horsie. Chlapik v BA mi pri zachrane disku povedal, ze tam mava pravidelne placucich adminov, ktori si myslia, ze RAID je svatena voda, ktora vsetko riesi a velmi sa cuduju, ze ked cely RAID klakne, sanca na zachranu je milion-nasobne mensia ako pri jednotlivom HDD. Takze dovolim si poopravit, zalohovanie dnes vieme realizovat jedine kombinaciou tychchto faktorov: 1) Kopirovanim dat na novsie a novsie nosice - aj novsie generacie nosicov, pretoze tie zasratavaju jednak moralne a jednak fyzicky. Nikto neskusal precitat nieco po 500 rokoch, simulacie su na nic. Plati nepriama umera: cim viac dat, tym menej su trvacne. Ryhy na kosti vlka predstavuju zopar bajtov, ale vo volnej prirode prezili 50 tisic rokov. Hieroglyfy na egyptskych skalach (ci "kamenne" pisma inych civilizacii) predstavuju radovo kilobajty az desiatky kilobajtov a prezili 5 tisic rokov. Staroveke zvitky (knihy v staroveku neexistovali) predstavovali mozno uz niekolko desiatok kB ci radovo sto kB a prezili by tiez mozno tisicrocie (keby iní chuji nevypalili Alexandrijsku knihnicu). Knihy obsahujuce radovo stovky kB dat vydrzia storocia (potom sa bohuzial zacnu rozpadavat ako vsetko po istom case, treba kvalitny papier a specialne podmienky skladovania). Jednoducho ako pribuda kapacita, ubuda trvacnost. Dnesne 4 TB disky si istotne nezachovaju data 50 tisic, 5 tisic rokov, ani 500 ci 50 rokov ale blizsie realite je 5 rokov. Samozrejme pri zaobchadzani v kuravickach. 2) Nezavislou redundanciou dat. T.j. mat to na viacerych (dvoch-troch) miestach naraz. Ako som ale pisal vyssie, RAID nie je tento typ, pretoze tie disky nie su nezavisle. Riadi ich softver a hardver RAID pola a ked zlyha ovladanie RAID pola, data budeme tazko dolovat. Idealne je mat teda data na 2-3 diskoch UPLNE, SEPARATNYCH a teda nijako nezavislych. Samozrejme niekto moze vidiet problem, kto to tam bude stale kopirovat. Na to staci disky pripojit raz za den/tyzden/mesiac alebo ako casto chceme a pripravenym batakom si tam v noci (zakial budeme spinkat) natrieskat co chceme ...
nManJofo
Nie je RAID ako RAID samozrejme... pokial mi lahne radic na 5-kovom poli, tak je to pruser, ale u jednotky by to nemal byt problem, nakolko oba disky obsahuju rovnake data.
Pjetro_de
Samozrejme zalezi od RAIDu, sak ich je aj tucet druhov ... Jediny "neohrozeny" by teoreticky mohol byt ten jednoduchy mirroring (na ktory stacia 2 disky), resp. aj velke RAIDy obsahujuce v konecnom dosledku mirroring, aj ked na tom visi napr. 0 ci replikacia celeho pola. Vsetko ostatne co vobec neobsahuje mirroring je dost ohrozene najme 5 a 6. Je sice pekne ze pri 5tke (min 3 disky) moze zlyhat jeden lubovolny disk a pri 6tke (min 4 disky) mozu zlyhat lubovolne dva. Ked zlyha cely RAID, data na kazdom disku su uplne na prd.
Hiro
Ani ten nebude moc super. Staci nejaky vyboj ci skrat kde odidu oba disky naraz. Ja to riesim tak ze mam externy disk kde synchronizujem zalohu kazdy tyzden a inak je vypnuty, odlozeny.
felipe25
Napodobne, super clanok... Vecer vyskusam na dvoch kartach a jednom USB ktore mi uz rok potom co ich getdataback nevie rozchodit, a system ich detekuje.. snad pomoze :)
felipe25
Strana 5: "3.Nabootujte z USB kľúča, bude Vás čakať terminál. V prvom rade musíme disky v systéme identifikovať. K tomu slúži utilita fdisk. Do terminálu napíšte: " mam problem, po boote vidim akesi menu: 1. default 2. start/install ubuntu /myslimP. 3. boot from first harddrive atd.. co mam zvolit? vyskusal som 1 aj 2, no potom zacne len blikat kurzor... ak napisem : sudo fdisk -l nic sa nedeje.. ale ani nevidim ubuntu@ubuntu: ? Co s tym? Diky
nManJofo
Tam len hodit enter a to ubuntu by malo startovat
felipe25
Pytam sa dalej v sekcii vo fore: http://pretaktovanie.zoznam.sk/viewtopic.php?f=13&t=96090 Čítajte viac: http://pc.zoznam.sk/node/16349/talk#comment-50026#ixzz2fpppXac5
pauco
Musim napisat pochvalny koment. Clanok sa cita velmi dobre, ma to hlavu aj patu a na konci konkretny priklad, palec hore.
Pridať nový komentár
TOPlist