Întoarceți-vă de la abis sau restaurați fișierele pe UNIX
div.main Întoarcerea de la abis sau restaurarea fișierelor în UNIX Layem Widdousson, John Ferlito
Situația, atunci când un fișier important este șters în mod accidental, purtând toți biți și octeți în uitare, este un adevărat coșmar pentru orice administrator de sistem. În cele mai multe cazuri, aceasta este mai mult o inconvenientă decât o tragedie, deoarece fișierele pot fi restaurate utilizând o copie de rezervă actualizată în mod regulat.
Cu toate acestea, dacă un administrator de sistem sau un dezvoltator a efectuat modificări semnificative ale fișierului de la ultima copie de rezervă a fișierului, este posibil să se piardă o cantitate corectă de date. Situațiile neplăcute nu se limitează la acest lucru: scenarii de rezervă configurate incorect, defecțiuni hardware sau, în final, ghinion simplu. Nimic nu poate înlocui o strategie de rezervă adecvată. Nu punem la îndoială această îndoială, în acest articol ne concentrăm asupra metodelor de restaurare completă sau parțială a fișierelor din sistemul de fișiere UNIX.
UNIX FILE SYSTEM
Fișierele din UNIX sunt containere de date logice. Fiecare fișier este asociat așa-numita structură inod (inode, indicele de-nod structura), care conține metadate (blocuri de disc în care se află fizic de fișiere), informații despre proprietarul fișierelor, permisiunile de acces, dimensiunea și așa mai departe. D. La demontarea fișierului index descriptorii nu sunt șterși fizic de pe disc, ci sunt marcați ca fiind gratuite. Datele conținute în astfel de fișiere sunt încă stocate pe disc și pot fi recuperate dacă informațiile noi nu au fost încă înregistrate în locul lor.
RETURNAȚI DIN BOTTĂ
$ ./nph-www.pl> nph-www.pl
Această comandă a transformat fișierul cu codul Perl într-un fișier cu octet zero. Situația este agravată de faptul că modificările făcute în timpul săptămânii, nu au fost aduse în sistemul de control al bazei de date angajat de revizuire (Concurrent Versions System, CVS), ceea ce a însemnat pierderea a aproximativ 600 de linii de cod. Când a raportat ce sa întâmplat, să o liniștească, spunând că, de fapt, nu există nici o problemă mare, deoarece fișierul pot fi recuperate din copia de rezervă, care a fost făcut noaptea trecută, și că ea va trebui să recupereze doar codul scris astăzi.
Am sunat pe administratorul nostru de sistem și l-am rugat să restaureze dosarul care ne interesează. Cu toate acestea, nu am primit răspunsul pe care l-am așteptat - administratorul de sistem a recunoscut că nu a auzit niciodată despre serverul de dezvoltare și, prin urmare, acest server nu a fost rezervat.
Angajat, sa resemnat faptul că sistemul de fișiere UNIX nu poate restabili un fișier șters anterior, am pregătit să-mi petrec toate zilele în afara re-scrierea acestui cod. Ea a fost asigurată că este posibilă restaurarea dosarului, însă acest lucru va dura mai multe ore. Rețineți că astfel de povesti neplăcute se întâmplă nu numai cu administratorii neexperimentați. Cu câțiva ani în urmă, lucrând în Linux, unul dintre noi a scris în mod accidental crontab -d în loc de crontab -e. Câți cititori vor fi utilizatorii care fac backup / var / spool / cron / crontabs?
RESTORING UNIX FILES
# mount -o ro, remount -n / home
Principalul lucru nu este să permiteți blocarea blocurilor sau a descriptorilor de inode revendicați anterior de fișierul la distanță care să fie suprascrise de alte procese. Acest lucru este valabil mai ales dacă această secțiune este aproape completă, deoarece probabilitatea de reutilizare a descriptorilor indexului șters este semnificativ crescută. Dacă gradul de partiționare este mic, procedura de recuperare poate fi efectuată direct pe partiția de citire și scriere a discului, deși, după cum sa menționat mai sus, șansele de recuperare sunt inevitabil reduse.
Următoarele descriu procedurile pentru restaurarea fișierelor în sistemele UNIX. Prima secțiune este dedicată metodei de recuperare a fișierelor cu conținut cunoscut, care este aplicabilă pentru aproape toate soiurile sistemelor de fișiere UNIX. Cel de-al doilea analizează particularitățile recuperării fișierelor în sistemul de fișiere ext2 Linux.
PROCESUL DE REZOLVARE A FILDELOR CU CONȚINUTUL CUNOSCUT
După ce sistemul a fost transferat într-o stare sigură, trebuie să utilizați comanda dd (1) pentru a face o copie a datelor originale ale partiției care conține fișierul șters. Să presupunem că fișierul / etc / passwd a fost șters din greșeală. Următorul exemplu ilustrează procedura pentru crearea unei copii a partiției rădăcină și apoi plasarea acesteia într-un fișier din partiția / export:
Partiția țintă trebuie să fie suficient de mare pentru a acoperi întreaga partiție sursă (în acest caz, aproximativ 128 MB). Dacă sistemul nu are spațiul necesar pe disc, trebuie să vă gândiți la acțiuni alternative, cum ar fi montarea unei partiții la distanță utilizând NFS sau efectuarea de acțiuni direct pe fișierul dispozitivului de partiționare.
După ce se face o copie a sistemului de fișiere, sistemul poate fi returnat în modul multi-utilizator și poate continua să funcționeze cu acesta în modul normal. În cazul în care copia eșuează, sistemul ar trebui să fie lăsat într-o stare sigură, și înlocuiți numele dispozitivului în numele fișierului (în exemplul de mai jos, / dev / dsk / c0t3d0s0 se înlocuiesc cu /export/recover.dsk).
Procedura descrisă mai jos este mai degrabă artă decât știință. Permiteți ștergerea fișierului numit passwd. În partea stângă a instrucțiunii următoare, comanda pisică (1) reflectă toate "șirurile" de pe disc (opțiunea -n asigură ieșirea numerelor de linie). Apoi, ieșirea este redirecționată către utilitarul fgrep (1), iar cel de pe expresia regulată specificată efectuează o căutare "rapidă" pentru intrarea rădăcină din fișierul passwd:
În exemplul nostru, versiunile fișierului / etc / passwd au fost stocate pe disc în trei locuri. Versiunea GNU a utilitarului grep (1) oferă opțiunile -A și -B, care vă permit să imprimați mai multe linii înainte și după modelul găsit pe șablon. Acest lucru facilitează extragerea conținutului întregului fișier șters. Dacă versiunea grep (1) a versiunii GNU nu este instalată pe computerul dvs., puteți folosi programul pe căutări numite Cu în listare 1. Se imprimă întregul fișier, începând cu un anumit decalaj în octeți sau linii. Programul searchcat oferă doi parametri independenți: primul este indicat cu flagul -b sau -l, urmat de un număr întreg indicând decalajul în octeți sau liniile din care ar trebui să înceapă listele. Al doilea parametru este specificat sub forma semnalizării -f, iar apoi este specificat numele fișierului, care în acest caz este "imaginea de disc" a datelor sursă. De exemplu:
Același rezultat poate fi obținut prin specificarea utilității searchcat a șirului inițial. Acest număr este luat din imprimarea obținută ca urmare a comenzii cat -n, descrisă anterior în secțiunea curentă. Programul searchcat va afișa conținutul fișierului, pornind de la locul în care a fost găsit șirul care corespunde șablonului. În exemplul următor, sunt afișate 10 linii ale "imaginii de disc", începând cu prima linie găsită (linia după numărul 200 600). Dacă este necesar, puteți repeta procesul prin specificarea numărului liniei următoare (în exemplul nostru numărul său este 202 098):
PROCESUL DE RECUPERARE A FILEI LA LINUX
Este vorba de procesul de recuperare a fișierelor pe un sistem Linux dacă au fost șterse de comanda rm (1). Tehnica descrisă aici, ca regulă, garantează restaurarea fișierelor și nu se bazează pe principiul încercării și erorii. Avantajul său suplimentar este că vă permite să restaurați cu ușurință fișiere binare, precum și fișiere cu conținut necunoscut.
Instrumentul folosit în procesul de recuperare este cunoscut ca debuggerul debugfs (8), care este de obicei folosit pentru a verifica și schimba starea. Deși următoarele exemple sunt scrise pentru Linux, teoretic, ar trebui să fie valabil pentru orice tip de sistem de fișiere UNIX, cu condiția ca acesta conține mijloace cu debugfs funcționalitate (8). Dacă nu există o astfel de unealtă, va trebui să utilizați metoda de restaurare a fișierelor cu conținut cunoscut.
Aici este necesar să spunem că debugfs este un instrument puternic, dar în același timp extrem de periculos. Oferă acces direct la sistemul de fișiere, deci trebuie să aveți grijă în timpul sesiunii.
Utilitarul debugfs (8) oferă o interfață pentru tipul de interfață shell. Vom fi interesați de trei comenzi: lsdel, pisică și dump. Executați debugfs (8) în partiția necesară, după cum urmează:
Din ieșirea din lsdel, puteți afla care dintre descriptorii inode eliminați sunt de interes pentru noi. Coloanele din lista sunt cele mai importante: Proprietar, Dimensiune, Mod și Ora șterse. Dacă din momentul ștergerii fișierelor nu s-au efectuat operații ulterioare cu discul, atunci descriptorii care ne interesează vor fi la sfârșitul listei. Câmpul Proprietar conține ID-ul de utilizator al proprietarului fișierului a cărui valoare poate fi găsită în al treilea câmp al fișierului / etc / passwd. În exemplul nostru, numele proprietarului este johnf (identificatorul 1000), iar fișierul conține un singur șir de date importante.
În lista de mai sus, un descriptor (inode) cu numărul 32605 se află la sfârșitul listei și, prin urmare, este primul candidat pentru verificare. Conținutul corespunzător acestui descriptor poate fi derivat după cum urmează:
debugfs: cat <32605> important_data
Deci, fișierul șters este găsit. Comanda dump "resurează" fișierul, scriind pe disc:
debugfs: dump -p <32605> / tmp / recovered_file
Opțiunea -p asigură că fișierul rămâne același ca și proprietarul, grupul și drepturile de acces.
Instalarea recuperării este destul de simplă:
# tar zxf recuperare-1.3.tar.gz # cd recuperare-1.3 # make # make install
Implicit, utilitarul este instalat în sistemul de directoare cu root / usr. Citiți fișierul README care descrie cum se instalează în alt sistem de directoare. În timpul sesiunii, programul de recuperare pune câteva întrebări simple, de exemplu:
care deține fișierele? când aceste fișiere au fost șterse? Care este dimensiunea aproximativă a acestor fișiere?
Folosind informațiile obținute, recuperarea începe debugfs, restabilește inodurile corespunzătoare acestui criteriu și le plasează în directorul specificat de utilizator.
Din păcate, spre deosebire de conținutul fișierelor, numele lor nu pot fi restabilite. Fișierele recuperate primesc nume constând din dump-ul prefixului și numărul inodului ulterior. Dacă ștergeți un director ca / etc, sute de fișiere pot fi pierdute. Pentru a sorta fișierele recuperate, puteți utiliza utilitare simple UNIX, dintre care șiruri (1) și fișier (1) sunt cele mai utile.
Șirul de programe (1) afișează secvența de caractere ASCII, extragându-l din fișierul specificat. Acest utilitar este folosit de obicei pentru a "scoate" textul din fișierele binare care nu pot fi decriptate în alte moduri.
Acesta este modul în care fișierul (1) funcționează pentru directorul cu fișierele restaurate:
Clasificați fișiere de diferite tipuri prin adăugarea de extensii de fișiere la numele fișierelor utilizând un script de shell simplu. De exemplu:
În acest caz, puteți aplica utilitarul șiruri (1) afișând toate șirurile de text ASCII conținute în fișierul binar. De exemplu:
Conform acestui text, puteți ghici că acest fișier este un fișier executabil groff (1). Rularea acestuia pentru a fi executată cu opțiunea --help confirmă acest lucru. Cu bibliotecile, este ceva mai dificil, pentru că nu pot fi difuzate. Aici ajungem la echipa de salvare objdump (1). De exemplu:
# objdump -p dump34756.lib | grep SONAME SONAME libmenu.so.4
Nici o metodă de recuperare nu va înlocui copiile de rezervă ale datelor create în mod regulat și în întregime pe suporturi de încredere. Procedurile descrise mai sus au ca scop să ajute administratorii de sistem care se află la un prag de abis.
Articole similare
Trimiteți-le prietenilor: