Avertisment: Notă: conținutul este destinat divertismentului. Densitatea informației utile este mică. A fost scris „pentru mine”.
Introducere lirică
Gunoaiele de fișiere din organizația noastră se află pe o mașină virtuală VMware ESXi 6, sub Windows Server 2016. Și nu este doar un simplu gunoi. Acesta este un server de schimb de fișiere între departamente: aici se află colaborarea, documentația de proiect și foldere cu scanere de rețea. În general, aici este întreaga activitate de producție.
Și iată că acest recipient al întregii vieți de producție a început să se blocheze. În plus, un oaspete se putea bloca singur, fără a afecta pe ceilalți. Putea bloca tot hostul și, prin urmare, toate celelalte mașini virtuale. Putea să se blocheze singur și să blocheze serviciile clientului vSphere: adică procesele celorlalte oaspeți erau active, mașinile funcționau corect și răspundeau, dar gunoaiele de fișiere nu și clientul vSphere nu se conecta la host. În general, nu se putea identifica niciun sistem. Blocajele puteau apărea ziua, în timpul unei încărcări reduse. Puteau să apară noaptea, în timpul unei încărcări nule. Puteau să se întâmple noaptea, în timpul unei backup diferențiale și a unei încărcări medii. Puteau să aibă loc în weekenduri, în timpul unui backup complet și a unei încărcări ridicate. Și s-a observat o degradare evidentă a situației. La început, se întâmpla o dată pe an, apoi o dată la șase luni. Spre finalul răbdării mele - de două ori pe săptămână.
Am suspectat că este din cauza memoriei RAM. Dar nu am putut opri gunoiul nici măcar în weekend și să rulez Memtest. Am așteptat să vină sărbătorile de mai. În sărbătorile de mai, am rulat Memtest și... nu au fost găsite erori.
Am rămas uimit și am decis să merg în concediu. În timpul concediului meu, gunoiul nu a avut nicio blocare. Iar când luni am revenit la lucru - gunoiul era blocat. A trecut peste backupul complet și exact după terminarea acestuia s-a blocat. Această primire călduroasă de la concediu m-a determinat să decid să mut fizic discurile cu mașina virtuală pe un alt host.
Și, deși se știe demult că în prima zi după concediu nu trebuie să faci nimic serios, deși pe tot drumul spre lucru m-am pregătit să nu lucrez, indignarea mea față de blocajul următor mi-a șters din minte pregătirea și promisiunile...
Discurile fizice au fost mutate pe un alt host. Conectare la cald. În setările stocării, pe fila Discuri discurile apar. Pe tab-ul Datastores nu sunt stocuri pe aceste discuri. Reîmprospătare — nu apar. Și, desigur, primul impuls — Adaugă Stocare. Asistentul de adăugare explică ce suportă. Desigur, suportă și VMFS. N-am avut îndoieli. Am trecut repede prin mesajele asistentului la fiecare pas: Următorul, Următorul, Următorul, Finalizare. Privirea nu s-a oprit nici măcar asupra micii cercuri galbene cu semnul exclamării din partea de jos a ferestrei unui dintre pașii asistentului.
După finalizarea asistentului, noul Datastore a apărut în listă… împreună cu Datastores de pe celelalte discuri fizice.
Trec la navigarea prin noul Datastore adăugat, iar el… este gol. Desigur, am căzut din nou în uimire. Era ora 8 dimineața, primele 15 minute la lucru după concediu, nici măcar zahărul din cafea nu l-am amestecat încă. Și aici a apărut asta. Prima mea gând a fost — nu am tras discul corect din gazda 'nativă'. Am verificat dacă Datastore-ul dorit era în gazda 'nativă': nu, nu era prezent. Al doilea gând a fost: „m@#ă!”. Nu sunt sigur, dar cred că al treilea, al patrulea și măcar al cincilea gând au fost la fel.
Pentru a-mi răspunde la întrebări, rapid am instalat pentru testare un nou ESXi, am luat un disc făcut pe 'lat', și, citind atent, am parcurs pașii asistentului. Da. Când adaugi Datastore folosind asistentul, pierzi toate datele de pe disc fără posibilitatea de a reveni asupra operațiunii și de a recupera datele. Mai târziu am citit pe un forum o evaluare a acestui design al asistentului: shitsome crap. Și am fost foarte de acord.
Începând cu al șaselea — gândurile au început să curgă într-o direcție mai constructivă. Bun. Inițializarea durează câteva secunde chiar și pentru un disc de 3 Tb. Asta înseamnă că este o formatare de nivel înalt. Asta înseamnă că a fost rescrisă doar tabela de partiții. Asta înseamnă că datele sunt încă acolo. Asta înseamnă că acum vom căuta un unformat și voila.
Încarc mașina de pe imaginea de boot Strelec… Și descopăr că programele de recuperare a partițiilor știu tot, cu excepția VMFS. De exemplu, cunosc partiționarea Synology, dar VMFS — nu.
Revizuirea programelor nu este îmbucurătoare: în cel mai bun caz, GetDataBack și R.Saver găsesc partiții NTFS cu structura de directoare activă și nume de fișiere active. Dar nu mă mulțumesc cu asta. Am nevoie de două fișiere vmdk: cu discul sistemului și discul cu fișierele de gunoi.
Și aici îmi dau seama că, se pare, că acum va trebui să instalez Windows și să recuperez din backup-uri de fișiere. În același timp, îmi amintesc că aveam acolo un director DFS. Și, de asemenea, există un sistem complet nebun de drepturi de acces pentru folderele departamentelor. Nu este o opțiune. Singura opțiune acceptabilă din punct de vedere al timpului este restaurarea stării sistemului și a discului cu datele și toate drepturile.
Din nou căutări pe Google, forumuri, KB-uri și din nou plângerea Iaroslavnei: VMware ESXi nu prevede un mecanism de recuperare a datelor. Toate discuțiile au două finaluri: cineva s-a recuperat cu ajutorul costisitorului DiskInternals VMFS Recovery sau cuiva i-a fost de ajutor un specialist care își promovează activ serviciile. vmfs-tools și dd. Opțiunea de a cumpăra licența DiskInternals VMFS Recovery pentru $700 nu este fezabilă. Permițând unei persoane străine de pe „teritoriu potențial inamic” acces la datele corporative nu este de asemenea fezabil. Totuși, s-a găsit că partițiile VMFS pot fi citite și de UFS Explorer.
DiskInternals VMFS Recovery
A fost descărcată și instalată versiunea trial. Programul a reușit să vadă partiția VMFS goală:
În modul Undelete (Scanare Rapidă) de asemenea, a găsit și Datastore-ul deteriorat cu folderele mașini virtuale cu discurile de interior:
Previzualizarea a arătat că fișierele sunt active:
Montarea partiției în sistem a fost reușită, dar din motive inexplicabile, în toate cele trei foldere era aceeași mașină virtuală. Desigur, din legea lui Murphy — nu era cea dorită.
Trei linii de rușineÎncercarea întreprinsă de a pirata nerușinat software-ul s-a terminat cu un eșec. Totuși, UFS Explorer a reușit să fie piratat.
Am o părere extrem de negativă despre furtul de software. Cu niciun chip nu îndemn la utilizarea mijloacelor de ocolire a protecției împotriva utilizării neautorizate.
Mă aflam într-o situație catastrofală și nu eram deloc mândru de măsurile la care am recurs.
UFS Explorer
Scanarea discului a arătat prezența a 7 noduri. Numărul nodurilor s-a potrivit „în mod surprinzător” cu numărul de fișiere *-flat.vmdk descoperite de VMFS Recovery:
Compararea dimensiunilor fișierelor și dimensiunilor nodurilor a arătat de asemenea o corespondență exactă. De asemenea, au fost recuperate numele fișierelor *-flat.vmdk și, în consecință, apartenența lor la mașinile virtuale.
În general, discurile vmdk din perspectiva ESXi constau din două fișiere: un fișier cu datele (<numele mașinii>-flat.vmdk) și un fișier de „fizică” a partiției discului (<numele mașinii>.vmdk). Dacă încărcați fișierul *-flat.vmdk dintr-o mașină locală în Datastore, ESXi nu îl va recunoaște ca un fișier valid de disc. În baza de cunoștințe VMware există un articol despre cum să creați manual un fișier descriptor al discului: , dar nu a fost necesar să fac asta, am copiat pur și simplu conținutul fișierelor corespunzătoare din zona de vizualizare a conținutului fișierului în DiskInternals VMFS Recovery:
După 4 ore de descărcare a nodului de 2,5TB din UFS Explorer și 20 de ore de încărcare în Datastore, fișierele de disc corupte au fost conectate la o mașină virtuală newly created. Discurile au fost recunoscute. Nu au fost observate pierderi de date.
Sursa: habr.com
