Oporavak VMDK datoteke: što učiniti kad virtualni disk zakaže

Ako se VMware virtualni stroj ne pokreće, a datastore javlja nestalu ili oštećenu VMDK datoteku, podaci su u većini slučajeva još uvijek na disku. Ishod oporavka ponajviše ovisi o tome što se dogodi u prvim satima. Na početku treba utvrditi je li riječ o logičkoj grešci, primjerice nestalom descriptoru ili prekinutom snapshot lancu, ili o fizičkom kvaru diska, RAID polja ili NAS-a na kojem se datastore nalazi. U ovom vodiču objašnjavamo od čega se VMDK disk sastoji, kako prepoznati vrstu kvara, koje korake poduzeti odmah i kada je pravo vrijeme da se obratite laboratoriju za spašavanje podataka.

Datarecovery

Sačuvajte podatke s virtualnog diska

Datarecovery je stručni laboratorij za oporavak podataka s diskova, RAID polja i NAS sustava kada VMDK zakaže.

Posjetite laboratorij

TL;DR

VMDK disk obično nije jedna datoteka. Sastoji se od malog tekstualnog descriptora i velike *-flat.vmdk datoteke u kojoj su stvarni podaci, a uz snapshotove dolaze i delta datoteke.
Prije bilo kakvog pokušaja popravka napravite kopiju flat datoteke na odvojenu lokaciju. Tako postupa i službena VMware uputa.
Ako datastore leži na disku, RAID polju ili NAS-u koji pokazuje znakove kvara, ne pokrećete ništa: svaki novi zapis smanjuje šanse za oporavak.
Snapshot lanci i delta diskovi najosjetljiviji su dio. Pogrešna konsolidacija ili ručni zahvat u lanac može trajno izbrisati novije podatke.
Kada su podaci poslovno važni, a nema provjerene sigurnosne kopije, najsigurniji put je laboratorijska dijagnostika prije bilo kakvog zahvata.

Sadržaj

Od čega se sastoji VMDK virtualni disk
Prvo pitanje: logička greška ili fizički kvar
Prvih 30 minuta: koraci koji čuvaju podatke
Najčešći scenariji i preporučeni put
Snapshot lanci: gdje nastaje najviše štete
Ransomware na ESXi poslužiteljima
Što se ne smije raditi
Kako izgleda laboratorijski oporavak VMDK-a
Kako smanjiti rizik idući put
Česta pitanja
Izvori

Od čega se sastoji VMDK virtualni disk

Mnogi administratori VMDK zamišljaju kao jednu veliku datoteku. U VMware okruženju virtualni disk najčešće čini nekoliko povezanih datoteka, a kvar na bilo kojoj od njih može spriječiti pokretanje virtualnog stroja.

Datoteka	Što sadrži	Što se događa kad je oštećena
ime.vmdk (descriptor)	Tekstualni opis diska: geometriju, tip diska, veličinu i poveznicu na flat datoteku	VM se ne pokreće, iako su podaci u flat datoteci često netaknuti
ime-flat.vmdk	Cijeli sadržaj virtualnog diska, sektor po sektor	Izravan gubitak podataka, ovisno o opsegu oštećenja
ime-000001.vmdk (delta)	Promjene nastale nakon snapshota	Gube se podaci nastali poslije snapshota ili se prekida lanac
.vmx, .vmsd	Konfiguracija stroja i popis snapshotova	Stroj se ne može registrirati ni pokrenuti, ali diskovi ostaju

Razlika u veličini je velika. VMware u svojoj uputi za ponovno stvaranje nestalog descriptora navodi primjer u kojem descriptor ima manje od 1 KB, dok flat datoteka sadrži cijeli virtualni disk od 10 GB. U praksi to znači da nestanak male datoteke može izgledati kao potpuni gubitak, iako su gotovo svi podaci na mjestu.

Kod snapshotova se slika dodatno komplicira. Prema Broadcomovom pregledu snapshotova u vSphereu, descriptor snapshota i delta VMDK datoteke po zadanim postavkama spremaju se na istu lokaciju kao i osnovni disk. Kada zakaže to spremište, istodobno su ugroženi i osnovni disk i sve njegove delte.

Prvo pitanje: logička greška ili fizički kvar

Prije svake odluke treba procijeniti gdje je problem nastao. Kod oštećenih virtualnih diskova jedan je slučaj kvar fizičkog medija na kojem datoteke leže, a drugi oštećenje same VMDK strukture. Postupak, rizik i trošak oporavka u ta dva slučaja potpuno su različiti.

Znakovi logičkog problema

Datastore je dostupan i drugi virtualni strojevi na njemu rade normalno.
U pregledniku datastorea vidite flat datoteku, ali descriptora nema ili je prazan.
VM javlja da ne može otvoriti disk ili da roditeljski disk nije pronađen.
Nakon brisanja ili konsolidacije snapshota pojavila se poruka o neusklađenom lancu.
Problem je nastao nakon migracije, kopiranja ili ručne promjene naziva datoteka.

Znakovi fizičkog kvara ispod datastorea

Host javlja I/O greške, timeoutove ili gubitak putanje prema spremištu.
RAID kontroler prijavljuje degradirano polje, ispali disk ili neuspješan rebuild.
NAS se ne podiže, glasniji je nego inače ili jedan od diskova klika.
Više virtualnih strojeva na istom datastoreu odjednom ima probleme.
Kopiranje flat datoteke staje uvijek na istom mjestu ili traje nerazumno dugo.

Kod fizičkog kvara svaki popravak VMDK strukture dolazi tek nakon što se podaci sigurno preslikaju s medija. Ako se nad oštećenim diskom pokreću provjere, rebuild ili popravak datotečnog sustava, oštećenje se može proširiti. Isto načelo vrijedi za svaki gubitak podataka, ne samo u virtualizaciji, što dobro opisuje ovaj vodič o tome kako brzo reagirati bez pogoršavanja gubitka podataka: prvo zaustaviti štetu, a tek onda popravljati.

Ako je spremište RAID polje, preporučujemo da pročitate i naš tekst o spašavanju podataka s RAID polja, jer se tamo najčešće donose odluke koje se kasnije ne mogu poništiti.

Prvih 30 minuta: koraci koji čuvaju podatke

Ovi koraci ne popravljaju ništa. Njihova je svrha zadržati postojeće stanje kako bi oporavak ostao moguć.

Zaustavite zapisivanje. Ako VM djelomično radi ili se ruši u petlji, isključite ga. Ne pokrećete ga opetovano “da vidite hoće li proći”.
Ne brišite i ne konsolidirajte snapshotove. Upozorenje “Needs Consolidation” u ovom trenutku nije prioritet. Konsolidacija, prema Broadcomovom opisu postupka, spaja delta datoteke natrag u osnovni VMDK, a nad oštećenim lancem to može trajno izbrisati stanje koje pokušavate spasiti.
Zabilježite stanje. Napravite snimke zaslona poruka o grešci, popis datoteka u mapi virtualnog stroja s veličinama i datumima, te zapise iz loga hosta i kontrolera.
Kopirajte flat i delta datoteke na odvojeno spremište. VMware u službenoj uputi najprije predviđa provjeru sigurnosne kopije, a ako je nema, kopiranje velike flat datoteke na drugu lokaciju. Tek se nakon toga razmatra rekonstrukcija descriptora.
Ako kopiranje zapinje, stanite. Ponavljanje kopiranja s fizički oštećenog medija opterećuje disk koji već otkazuje. U tom trenutku problem više nije VMDK, nego hardver.
Ne pokrećete rebuild RAID polja i ne mijenjate diskove napamet. Zamjena pogrešnog diska ili ponovna inicijalizacija polja jedna je od najčešćih situacija u kojima djelomičan gubitak postane potpun.
Procijenite vrijednost podataka. Ako na disku postoji baza, knjigovodstvo, poslovna pošta ili proizvodni sustav bez provjerene kopije, sljedeći korak je stručna dijagnostika, a ne eksperimentiranje.

Za širi pregled postupaka kod gubitka podataka u Hrvatskoj pogledajte naš vodič Hitni koraci za oporavak podataka i kada zvati laboratorij.

Najčešći scenariji i preporučeni put

Scenarij	Što se obično dogodilo	Preporučeni put
Nedostaje descriptor, flat je tu	Brisanje, neuspjela migracija, ljudska pogreška	Kopija flat datoteke, zatim rekonstrukcija descriptora prema točnim parametrima diska
Prekinut snapshot lanac	Ručno brisanje delte, pogrešna konsolidacija, pun datastore	Ne dirati lanac, sačuvati sve delte i dijagnosticirati redoslijed
Oštećen datotečni sustav unutar VM-a	Nagli prekid napajanja, rušenje gostujućeg OS-a	Raditi isključivo na kopiji diska
Datastore na neispravnom disku	Mehanički ili elektronički kvar, loši sektori	Laboratorijsko preslikavanje medija prije bilo kakvog logičkog rada
Degradirano ili srušeno RAID/NAS polje	Ispad više diskova, neuspio rebuild, kvar kontrolera	Prestati s radom na polju, laboratorijska rekonstrukcija
Šifrirane VMDK datoteke nakon napada	Ransomware na hipervizoru	Izolirati sustav, sačuvati stanje, procijeniti što je ostalo nešifrirano

Cijena i rok oporavka ovise upravo o tome u koji od ovih scenarija slučaj spada. Popravak samog descriptora i fizički kvar diska pod RAID poljem dva su potpuno različita posla, zbog čega pouzdana procjena dolazi tek nakon dijagnostike.

Snapshot lanci: gdje nastaje najviše štete

Snapshot nije sigurnosna kopija. On je točka u lancu: osnovni disk drži staro stanje, a svaka delta datoteka bilježi promjene nastale poslije. Descriptor svake delte upućuje na svog roditelja, a identifikatori sadržaja (Content ID) moraju se podudarati. Kada se lanac poremeti, VMware ga više ne može složiti u cjelinu.

Osnovni VMDK disk i povezane snapshot delte

VMware u uputi o rekonstrukciji descriptora jasno navodi da flat datoteku ne treba mijenjati, jer to može uzrokovati dodatni gubitak podataka. Ručno stvaranje descriptora ima smisla samo kada je problem ograničen na descriptor, a geometrija, tip diska i struktura lanca pouzdano su poznati.

Najčešće pogreške koje viđamo u praksi su:

brisanje “starih” delta datoteka radi oslobađanja prostora na punom datastoreu,
pokretanje VM-a izravno s osnovnog diska, čime se zaobilaze sve novije promjene,
uređivanje Content ID vrijednosti bez razumijevanja redoslijeda lanca,
višestruki pokušaji konsolidacije nakon prve neuspjele.

Svaki od ovih zahvata zapisuje novo stanje preko starog. Ako je lanac dugačak, a podaci u zadnjim deltama poslovno važni, to je trenutak za stanku i procjenu. VMware dokumentira i administratorsku provjeru i popravak virtualnog diska, ali taj postupak služi za konzistentnost diska na ispravnom spremištu. Nije zamjena za oporavak s fizički oštećenog medija i pokreće se tek nad kopijom.

Detaljniju kontrolnu listu za IT odjele donosi naš laboratorijski vodič za oporavak VMware datastorea.

Ransomware na ESXi poslužiteljima

Posebna kategorija su napadi usmjereni izravno na hipervizor. U veljači 2023. američke agencije CISA i FBI objavile su upute za oporavak virtualnih strojeva nakon napada ESXiArgs. Taj je ransomware ciljao ranjive ESXi poslužitelje i šifrirao konfiguracijske datoteke, zbog čega se virtualni strojevi nisu mogli pokrenuti.

Za oporavak su važna dva zaključka iz takvih slučajeva:

Šifriranje nije uvijek potpuno. Kada napadač šifrira samo konfiguraciju ili dio datoteka, podaci u velikim diskovnim datotekama mogu ostati čitljivi, a stroj se može ponovno složiti.
Prvi potezi odlučuju. Ponovna instalacija hosta, formatiranje datastorea ili brzopleto vraćanje starih kopija preko zaraženog sustava mogu uništiti upravo onaj dio koji je ostao netaknut.

Nakon napada sustav izolirajte od mreže, ne brišite ništa i sačuvajte stanje za analizu. Ako je potrebno utvrditi kako je do napada došlo, primjerice zbog prijave incidenta ili osiguranja, forenzička obrada mora se raditi na kopiji, uz dokumentirani postupak.

Što se ne smije raditi

Iz godina rada na oštećenim spremištima izdvajamo postupke koji najčešće pretvore rješiv slučaj u težak:

Pokretanje provjere datotečnog sustava nad originalom. Popravak “na licu mjesta” mijenja strukture koje su potrebne za rekonstrukciju.
Kopiranje na isti datastore. Ako je spremište oštećeno ili gotovo puno, nova kopija zauzima prostor u kojem su možda ostaci izgubljenih podataka.
Ponovna inicijalizacija ili rebuild RAID polja. Pogrešan redoslijed diskova ili pogrešni parametri polja prepisuju metapodatke.
Otvaranje diskova izvan laboratorija. Podatkovne ploče i glave za čitanje osjetljive su na prašinu, a otvoren disk izvan čiste komore trajno se oštećuje.
Isprobavanje više rješenja zaredom. Svaki pokušaj ostavlja trag, a stanje koje dođe u laboratorij nakon pet pokušaja bitno je lošije od izvornog.

Više o tome zašto vlastiti pokušaji često odmažu pročitajte u tekstu Uradi sam: spašavanje podataka, da ili ne?.

Kako izgleda laboratorijski oporavak VMDK-a

Laboratorijski oporavak virtualnog diska teče redom koji štiti izvornik u svakom koraku:

Prijem i dijagnostika. Utvrđuje se stanje fizičkih medija: diskova, SSD-ova, RAID ili NAS polja na kojem je datastore.
Preslikavanje medija. Svaki disk preslikava se na ispravan medij sektor po sektor. Mehanički oštećeni diskovi obrađuju se u čistoj komori.
Rekonstrukcija spremišta. Kod RAID i NAS sustava rekonstruiraju se parametri polja i datastore, isključivo na kopijama.
Analiza VMDK strukture. Provjeravaju se descriptor, flat datoteka i cijeli snapshot lanac, uključujući redoslijed i usklađenost delta datoteka.
Izdvajanje podataka. Ovisno o stanju, vraća se cijeli virtualni disk ili se iz njega izdvajaju datoteke, baze i dokumenti. Oštećene datoteke i baze po potrebi se popravljaju.
Provjera i predaja. Klijent dobiva popis spašenih podataka i provjerava ih prije preuzimanja.

Datarecovery (InfoLAB) od 1993. spašava podatke s hard diskova, SSD-ova, RAID polja, NAS uređaja i poslužiteljskih spremišta. Jedini smo laboratorij za spašavanje podataka u regiji s certifikatom ISO 9001:2015, a s mehanički oštećenim diskovima radimo u čistim komorama klase 100/10. Vrijedi pravilo “no Data, no Money”: ako podatke ne spasimo, ne plaćate oporavak. Kod hitnih slučajeva moguća je hitna intervencija. Ako je Vaš datastore, RAID ili NAS zakazao, a na njemu su virtualni strojevi s važnim podacima, obratite nam se za dijagnostiku i spašavanje podataka s RAID i NAS sustava prije bilo kakvog zahvata.

Kako smanjiti rizik idući put

Oporavak je posljednja linija obrane. Prva je dobro postavljena i provjerena sigurnosna kopija.

Europska središnja banka u vodiču iz 2025. o eksternalizaciji usluga računalstva u oblaku preporučuje odvojene politike sigurnosnog kopiranja i oporavka, fizički i logički odvojene kopije prema procjeni rizika te periodično testiranje točnosti, potpunosti i praktičnosti postupka. Vodič je pisan za nadzirane banke, ali ista načela vrijede za svaku tvrtku koja drži poslovne sustave na virtualnim strojevima.

Za VMware okruženje to u praksi znači:

Snapshotovi nisu backup. Leže na istom spremištu kao osnovni disk i nestaju zajedno s njim.
Kopija na odvojenom mediju i lokaciji. Barem jedna kopija mora biti izvan istog datastorea, istog polja i, idealno, iste zgrade.
Redovito testiranje vraćanja. Postojanje backup datoteke ne dokazuje da se VM može obnoviti. Provjerite pokreće li se sustav, rade li aplikacije i baze te jesu li dozvole i podaci konzistentni, i to u izoliranom okruženju.
Nadzor spremišta. Upozorenja RAID kontrolera i NAS-a o degradiranom polju treba rješavati odmah, a ne “kad bude vremena”.
Kontrola pristupa i zakrpe hipervizora. Napadi na ESXi u pravilu iskorištavaju poznate ranjivosti na nezakrpanim poslužiteljima.

Korak po korak postupak provjere opisali smo u vodiču Provjera backup integriteta, a razloge zašto bi tvrtke trebale redovito testirati kopije u tekstu Zašto korporacije trebaju testirati backup.

Česta pitanja

Mogu li se spasiti podaci ako je VMDK descriptor obrisan?

U većini slučajeva mogu, jer su podaci u flat datoteci, a descriptor je samo njezin mali tekstualni opis. Prije bilo kakve rekonstrukcije flat datoteku treba kopirati na odvojeno spremište. Ako uz descriptor nedostaju i snapshot delte ili je spremište fizički oštećeno, slučaj je složeniji i preporučujemo dijagnostiku.

Što ako je obrisana i flat datoteka?

Tada su na udaru sami podaci. Ishod ovisi o tome koliko se na datastore zapisivalo nakon brisanja i o stanju medija. Zapisivanje treba odmah zaustaviti, a spremište ne koristiti dok ga ne pregleda stručnjak.

Smijem li pokrenuti rebuild RAID polja na kojem je datastore?

Ne prije nego što ste sigurni zašto je polje degradirano i koji je disk stvarno neispravan. Rebuild nad polјem u kojem je još jedan disk na rubu kvara čest je uzrok potpunog gubitka. Kada su podaci važni, polje isključite i obratite se laboratoriju.

Koliko košta oporavak VMDK datoteke?

Cijena ovisi o vrsti kvara: popravak descriptora, oštećen snapshot lanac, korupcija datotečnog sustava ili fizički kvar diska, RAID ili NAS sustava. Zato se točna procjena daje nakon dijagnostike. Kod nas vrijedi pravilo “no Data, no Money”.

Oporavak VMDK datoteke: što učiniti kad virtualni disk zakaže

TL;DR

Sadržaj

Od čega se sastoji VMDK virtualni disk