Avertisment: Nota este în scop de divertisment. Densitatea specifică a informațiilor utile din acesta este scăzută. A fost scris „pentru mine”.
Introducere lirică
Depozitul de fișiere din organizația noastră rulează pe o mașină virtuală VMware ESXi 6 care rulează Windows Server 2016. Și aceasta nu este doar o groapă de gunoi. Acesta este un server de schimb de fișiere între diviziile structurale: există colaborare, documentație de proiect și foldere de la scanere de rețea. În general, toată viața de producție este aici.
Și acest container cu toată viața de producție a început să atârne. În plus, oaspetele se putea spânzura în liniște, fără a-i afecta pe ceilalți. Ar putea să doboare întreaga gazdă și, în consecință, toate celelalte mașini invitate. Aș putea să mă spânzur și să blochez serviciile client vSphere: adică procesele celorlalți oaspeți sunt vii, mașinile funcționează corect și răspund, dar nu există un spălator de fișiere și clientul vSphere nu se agață de gazdă. În general, nu a putut fi identificat niciun sistem. Înghețurile pot apărea în timpul zilei în timpul unei încărcări reduse. O puteau face noaptea fără încărcare. S-ar putea noaptea în timpul rezervării diferențiale și a sarcinii medii. S-ar putea în weekend în timpul backup-urilor complete și încărcării mari. Și a fost o degradare clară a situației. La început a fost o dată pe an, apoi o dată la șase luni. La sfârșitul răbdării mele - de două ori pe săptămână.
Am avut o problemă de memorie. Dar nu m-au lăsat să opresc grămada de gunoi nici măcar în weekend și să rulez Memtest. Asteptam sarbatorile de mai. În vacanțele din mai am alergat Memtest și... nu s-au găsit erori.
Am fost uimit și am decis să plec în vacanță. În timp ce eram în vacanță, nu a existat nici măcar o blocare la groapa de gunoi. Și când m-am întors la muncă pentru prima zi de luni, a fost un morman de gunoi. Am suportat o copie de rezervă completă și am blocat imediat după ce a fost finalizată. O primire atât de călduroasă din vacanță m-a împins la decizia de a trage fizic discurile cu mașina oaspeților la o altă gazdă.
Și, deși se știa de mult că nu poți face nimic serios în prima zi după o vacanță, deși mă pregăteam să nu muncesc până la muncă, indignarea mea față de încă un îngheț mi-a zguduit atât starea de spirit, cât și jurăminte din capul meu...
Discurile fizice au fost mutate pe o altă gazdă. Conexiune fierbinte. În setările de stocare din filă Unități apar discuri. Pe fila Depozite de date Nu există stocare pe aceste discuri. Reîmprospăta - nu apar. Ei bine, desigur, primul impuls - Adăugați spațiu de stocare. Expertul de adăugare explică ce acceptă. Desigur, acceptă și VMFS. Nu m-am îndoit de asta. O privire rapidă asupra mesajelor vrăjitorului la fiecare pas: Următorul, Următorul, Următorul, Terminarea. Ochiul nici nu s-a apropiat să surprindă micul cerc galben cu un semn de exclamare în partea de jos a ferestrei unuia dintre treptele maestrului.
La sfârșitul vrăjitorului, în listă a apărut și Datastore-ul proaspăt... și împreună cu el și depozitele de date de pe discurile fizice rămase.
Trec la navigarea prin Datastore-ul nou adăugat și este... gol. Desigur, am căzut din nou în uimire. E 8 dimineata, primele 15 minute la serviciu dupa vacanta, inca nu am amestecat zaharul din cafea. Și iată-l. Primul gând a fost că am scos discul greșit de la gazda „nativă”. M-am uitat să văd dacă Datastore-ul necesar era prezent în gazda „nativă”: nu, nu era prezent. Al doilea gând a fost: „La naiba!” Nu sunt sigur, dar mi se pare că al treilea, al patrulea și cel puțin al cincilea gând a fost același.
Pentru a risipi îndoielile, am instalat rapid un ESXi proaspăt pentru testare, am luat discul din stânga și, citindu-l deja, am parcurs pașii vrăjitorului. Da. Când adăugați un Datastore utilizând expertul, toate datele de pe disc se pierd fără posibilitatea de a derula înapoi operația și de a restabili datele. Mai târziu am citit pe unul dintre forumuri o evaluare a acestui design de către un maestru: rahat. Și chiar am fost de acord.
Începând de la a șasea, gândurile curgeau într-o direcție mai constructivă. BINE. Inițializarea durează câteva secunde chiar și pentru un disc de 3 Tb. Deci, aceasta este formatare la nivel înalt. Aceasta înseamnă că tabelul de partiții a fost pur și simplu rescris. Deci datele sunt încă acolo. Deci, acum vom căuta ceva neformat și voila.
Pornesc mașina din imaginea de boot Strelec... Și aflu că programele de recuperare a partițiilor știu totul în afară de VMFS. De exemplu, cunosc aspectul partiției Synology, dar nu VMFS.
Căutarea prin programe nu este liniștitoare: în cel mai bun caz, GetDataBack și R.Saver găsesc partiții NTFS cu o structură de directoare live și nume de fișiere live. Dar asta nu mi se potrivește. Am nevoie de două fișiere vmdk: cu discul de sistem și discul cu fișierul de gunoi.
Și apoi înțeleg că se pare că acum voi instala Windows și voi lansa dintr-o copie de rezervă a fișierului. Și în același timp îmi amintesc că aveam o rădăcină DFS acolo. Și, de asemenea, un sistem de drepturi de acces la folderele departamentelor, care este absolut sălbatic ca amploare și ramificații. Nu este o opțiune. Singura opțiune acceptabilă în timp este restabilirea stării sistemului și a discului cu datele și toate drepturile.
Din nou Google, forumuri, KB'shki și din nou plânsul Yaroslavnei: VMware ESXi nu oferă un mecanism de recuperare a datelor. Toate firele de discuții au două finalități: cineva a fost recuperat folosind scumpul DiskInternals VMFS Recovery sau cineva a fost ajutat de un specialist în software care își promovează în mod activ serviciile vmfs-tools и dd. Opțiunea de a cumpăra o licență DiskInternals VMFS Recovery pentru 700 USD nu este o opțiune. Permiterea unui străin de pe „teritoriul unui potențial inamic” să acceseze datele corporative, de asemenea, nu este o opțiune. Dar s-a căutat pe Google că partițiile VMFS pot fi citite și de UFS Explorer.
DiskInternals VMFS Recovery
Versiunea de încercare a fost descărcată și instalată. Programul a văzut cu succes partiția VMFS goală:
modul Anulați ștergerea (Scanare rapidă) Am găsit, de asemenea, un Datastore ponosit cu foldere de mașini virtuale cu discuri înăuntru:
Previzualizarea a arătat că fișierele sunt vii:
Montarea partiției în sistem a avut succes, dar dintr-un motiv necunoscut, toate cele trei foldere conțineau aceeași mașină virtuală. Desigur, conform legii, răutatea nu este ceea ce se cere.
Trei rânduri de rușineÎncercarea de a bloca fără rușine software-ul s-a încheiat cu un eșec. Dar UFS Explorer sa blocat.
Am o atitudine extrem de negativă față de furtul de software. În niciun caz nu încurajez utilizarea mijloacelor pentru a ocoli protecția împotriva utilizării fără licență.
Eram într-o situație catastrofală și nu eram deloc mândru de măsurile la care apelasem.
UFS Explorer
O scanare a discului a arătat prezența a 7 noduri. Numărul de noduri a coincis „în mod surprinzător” cu numărul de fișiere *-flat.vmdk detectate de VMFS Recovery:
O comparație a dimensiunilor fișierelor și a nodurilor a arătat, de asemenea, o potrivire până la octet. În același timp, au fost restaurate numele fișierelor *-flat.vmdk și, în consecință, apartenența acestora la mașinile virtuale.
În general, discurile vmdk din punct de vedere ESXi constau din două fișiere: un fișier de date (<nume mașină>-flat.vmdk) și un fișier de format de disc „fizic” (<nume mașină>.vmdk). Dacă încărcați un fișier *-flat.vmdk în Datastore de pe o mașină locală, ESXi nu îl va recunoaște ca fișier de disc valid. Baza de cunoștințe VMware are un articol despre cum să creați manual un fișier descriptor de disc: , dar nu a trebuit să fac asta, pur și simplu am copiat conținutul fișierelor corespunzătoare din zona de previzualizare a conținutului fișierului din DiskInternals VMFS Recovery:
După 4 ore de descărcare a unui nod de 2,5 TB din UFS Explorer și 20 de ore de încărcare în Datastore-ul hipervizorului, fișierele de disc prăbușite au fost conectate la mașina virtuală nou creată. Discurile au ridicat. Nu s-a observat nicio pierdere de date.
Sursa: www.habr.com