Blog történet egy mérnök, hogy megmentsék az adatokat a haldokló merevlemez

Üdvtörténet a „haldokló” merevlemez

Másnap reggel kezdődött a leolvasást levele smartd. Az egyik szerver meghajtó, mellyel a biztonsági másolatot az összes többi szervert, elkezdte útját egy jobb világot. A levél szerint a megjelenése a folyamatban lévő ágazatban. de amíg én vezettem a hivatal smartd jött a második levél, amely azt állította, hogy az ágazat már beköltözött a kategóriába elérhető javítható. De ez rossz, így nagyobb valószínűséggel olvasni az adatokat a szektor nem fog sikerülni.

Előretekintve azt mondani, hogy nem vagyok híve a „rejtett” probléma szektorok a lemezen, és használja őket tovább. Ha voltak problémák a leolvasást szektorok a lemezen, a megbízhatóság, a lemez már nem. Meg kell inkább leszerelt, és többé nem lehet használni (legalábbis szerverek). Most a költségek az új hajtások elég alacsony ahhoz, hogy megváltoztassa őket újakra.

Miután a hétvégén az új meghajtó van a szerver, és elkezdtem az adatok áthelyezéséhez. Ahhoz, hogy az előrehaladás figyelemmel kísérése minden olyan hely fut ülésén képernyőn

Használt a szerver virtualizáció OpenVZ és a backup szerver az egyik konténer. Már a kezdet kezdetén meg kell állítani, és tiltsa le az automatikus lejátszás esetén rendellenes újraindítás a fizikai szerveren.

On-die meghajtó elfoglalt több mint 50% -át a tér, a kis fájlok, és úgy döntöttem, hogy át adatokat a blokk szinten. Ehhez meg kell leválasztani a partíciót, és megakadályozzák, hogy önműködő (ismét, abban az esetben a rendellenes újraindítás)

Mivel volt a tapasztalatom azzal a problémával, másolás adathordozók, rögtön elmentem keresni ddrescue alatt CentOS. Ellentétben a klasszikus dd, ddrescue adatokat olvas a nagy tömb, de ha voltak hibák csökkenti blokk méretét és újraolvassa a sikertelen rész. Ez vezet jelentős csökkenését a sebesség a másolás, de miután áthaladt a problémás területen, a blokk méretét ismét növekszik, és a sebesség ismét növekszik. Megfelelő csomag található a tárolóban EPEL

Érdemes megemlíteni, hogy két különböző változatban ddrescue. Az eredeti változat 1 írta Kurt Garloff. Később GNU alap továbbfejlesztett változata 2-ben megjelent, amely elnyelt minden erőssége.

Abban a reményben, hogy az adatokat az olvashatatlan kicsit, hazamentem.

Másnap vártam jelentést ddrescue

A jelentés szerint nem csak olvasható 13 szektor. Most már nem tudom, hogy ebben az ágazatban a foglalkoztatási adatok, vagy éppen üres terület a lemezen. Következő schag - ezek az ágazatok tartoznak, hogy melyik fájlokat (és tartozik van egyébként).

A jelentés azt mutatja, ddrescue abszolút száma lemezszektorokat (kezdő szektor száma 0), és ez azt jelenti, hogy a további munkát, amit meg kell tanulni, hogy mit és milyen szektor van egy rész a lemezen tárolt adatokat.

Mivel a partíció kezdődik szektor 64, akkor számolni kell a szektorok számát elejétől ebben a szakaszban, és mozgassa a szektorok számát a blokkban számokat. Először is elismerik a fájlrendszer blokkméretet ágazatokban.

Mivel a blokk mérete 4096 bájt, és a fizikai szektor mérete 512 byte, a blokk mérete 8 fizikai szektorok. Következésképpen az átváltási képlet lesz (LBAN - 64) / 8

Rész hibás szektorok tartoznak azonos blokkokat, meghatározzák egyedi blokkszámokat

Itt vagyok egy kicsit megkönnyebbült, blokk számok folyamatosan nőnek, és nagy a valószínűsége, hogy minden tartozik csak egy fájlt. Továbbra is nézd meg - ismerve a blokk számokat lehet meghatározni, hogy ezeket alkalmazzák, és ha alkalmazunk, amit a fájl sérült. Az adatok partíciót ext3 fájlrendszer az alacsony szintű munka ez debugfs eszköz. Elindítása után meg kell nyitni a partíció a / dev / sdd1. Nyitva a szakaszt 2TB tovább tartott, mint amire számítottam, és meg kellett várni.

Azt ellenőrzik, hogy a blokkok 68307918, 68307919, 68307920 és 68307921 foglalt adatok (blokkok egy sorban, és én ahelyett, hogy felsorolja a kezdő és a szám)

A csoda nem történt, bár az adatok egy részét sérült. Továbbra is, hogy melyik fájlokat érintette. Ehhez össze a blokkok száma a inode tartozó, ezek az egységek.

Valamivel jobb 4 érvénytelen blokk 3 tartoznak a különböző leírója. Meg kell még neveket a fájlok vagy könyvtárak, amelyek megfelelnek ennek a leírója.

Hooked fájlok lépésekben egyik vizsgálati helyek. Ez az oldal nem sokat ér, és hát „hogy a kupac.” Most már lélegezni, és ki debugfs.

Később úgy döntöttem, hogy egy kis kísérlet, amely azt mutatja, hogy az ext3 fsck nem észleli a károkat az adatterület.