Istoricul salvării datelor de pe un hard disk "pe moarte"
În dimineața următoare a început să citească o scrisoare de la smartd. Una dintre unitățile de servere, care este folosită pentru backup-ul tuturor celorlalte servere, și-a început călătoria într-o lume mai bună. Scrisoarea se referea la apariția unui singur sector în curs. dar în timp ce mergeam la birou de la smartd a venit oa doua scrisoare, care a spus că acest sector a trecut deja în categoria offline uncorrectable. Dar acest lucru este deja rău, înseamnă că există un grad ridicat de probabilitate ca datele din acest sector să nu mai fie posibile.
Privind în perspectivă, voi spune că nu susțin "ascunderea" sectoarelor problematice pe discuri și le folosesc în continuare. Dacă discul are probleme la citirea sectoarelor, atunci nu există încredere într-un astfel de disc. Trebuie să fie dezafectată mai devreme și să nu mai fie folosită (cel puțin în servere). Acum, costul noilor unități este suficient de scăzut pentru a le schimba la cele noi.
După weekend, noul disc a fost instalat pe server și am continuat migrarea datelor. Pentru a putea monitoriza progresul din orice loc, execut sesiunea de ecran
Serverul utilizează virtualizarea OpenVZ, iar serverul de rezervă este unul dintre containere. Pentru început, trebuie să opriți și să dezactivați autorun în cazul unui restart anormal al serverului fizic.
Pe discul murdar, mai mult de 50% din spațiu a fost ocupat, cu fișiere mici, și am decis transferul datelor la nivel de bloc. Pentru a face acest lucru, trebuie să demontați partiția și să împiedicați automatizarea ei (din nou, în cazul unei rebootări anormale)
Deoarece am avut deja experiență de copiere a datelor de la purtători de probleme, m-am dus imediat să caut ddrescue sub CentOS. Spre deosebire de dd-ul clasic, ddrescue citește datele în blocuri mari, dar atunci când apar erori, reduce dimensiunea blocului și reiterează partea nereușită. Acest lucru duce la o reducere semnificativă a vitezei de copiere, dar după trecerea prin zona problemei, dimensiunea blocului crește din nou și viteza crește din nou. Pachetul necesar a fost găsit în depozitul EPEL
Aici merită menționat faptul că există două versiuni diferite ale lui ddrescue. Versiunea originală 1 a fost scrisă de Kurt Garloff. Ulterior, Fundația GNU a lansat o versiune îmbunătățită 2. care a absorbit toate aspectele cele mai puternice.
În speranța că vor fi date puțin greu de citit, m-am dus acasă.
A doua zi am așteptat un raport ddrescue
Potrivit raportului, doar 13 sectoare nu au putut fi citite. Acum nu știu dacă aceste sectoare erau ocupate cu date sau erau pe o zonă neocupată a discului. Următorul pas este să determinați ce fișiere aparțin acestor sectoare (și dacă acestea aparțin deloc).
Raportul ddrescue arată numărul absolut al sectoarelor discului (începând cu numărul sectorului 0), ceea ce înseamnă că pentru o muncă ulterioară trebuie să aflu din care și pe ce sector se află partiția de date de pe disc.
Deoarece secțiunea începe cu sectorul 64, trebuie să recalculați numerele sectorului în raport cu începutul secțiunii și să traduceți numerele de secțiuni în numere de bloc. În primul rând, știm dimensiunea blocului de sisteme de fișiere din sectoare.
Deoarece dimensiunea blocului este de 4096 octeți și dimensiunea sectorului fizic este de 512 octeți, dimensiunea blocului este egală cu 8 sectoare fizice. Prin urmare, formula de recalculare va fi (LBAN-64) / 8
O parte din sectoarele corupte aparțin acelorași blocuri, definim numere bloc unice
Aici m-am simțit puțin mai bine, numărul blocurilor merge succesiv și există o mare probabilitate ca toți să aparțină unui singur fișier. Rămâne să verificați acest lucru - știind numărul de blocuri pe care le puteți determina dacă sunt ocupați și dacă sunt ocupați, care fișier a fost corupt. Partiția de date utilizează sistemul de fișiere ext3, iar utilitarul debugfs este proiectat pentru a lucra cu un nivel redus. După pornire, trebuie să deschideți partiția / dev / sdd1. Deschiderea secțiunii pe 2TB a durat mai mult decât mă așteptam și a trebuit să aștept.
Am verificat dacă blocurile 68307918, 68307919, 68307920 și 68307921 sunt ocupate de date (blocurile rulează succesiv și în loc de enumerare am indicat inițial și numărul)
Miracolul nu sa întâmplat, dar unele date sunt deteriorate. Rămâne să aflăm care fișiere au fost afectate. Pentru a face acest lucru, trebuie să harta numerelor blocurilor în inodurile cărora le aparțin aceste blocuri.
Puțin mai bine, 4 blocuri deteriorate aparțin 3 inode diferite. Rămâne să aflați numele fișierelor sau directoarelor care corespund acestor inode.
Conectați fișierele incrementale ale unuia dintre site-urile de testare. Acest site nu are mare valoare și este susținut până la morman. Acum puteți expira și a ieși din fișierele debug.
Mai târziu, am decis să fac un mic experiment care arată că fsck pentru ext3 nu poate detecta corupția în zona de date.
Trimiteți-le prietenilor: