Dataherstel van virtuele VMDK- en VHDX-schijven

Een virtuele disk kan afhangen van descriptor, extent, snapshot en parent; een foutieve consolidatie mengt blokken uit verschillende momenten.

Offerte aanvragen

Schadebeeld

Alle onderdelen van de virtuele disk inventariseren

De volledige keten is de bron, want een virtuele schijf is zelden één autonoom bestand. VMware kan een kleine descriptor, één of meer flat- of sparse-extents en redo-logs gebruiken. Hyper-V bewaart parentlocators en block allocation tables in VHDX, terwijl QCOW2 backing files, refcounttabellen en interne snapshots kan bevatten. Voor dataherstel wordt daarom de volledige directorystructuur gekopieerd, inclusief configuraties, logboeken en verborgen nevenbestanden.

Per bestand worden oorspronkelijke naam, pad, grootte, tijdstempels, UUID of CID en een controlehash vastgelegd. Hypervisorconfiguratie toont welke disk aan welke controller en VM gekoppeld was. Datastorelogs kunnen de volgorde van snapshotcreatie, migratie, mislukte consolidatie of storage-uitval verduidelijken. Deze inventaris verhindert dat een toevallig groot bestand automatisch als laatste geldige toestand wordt behandeld.

Ook de onderliggende opslag hoort bij de diagnose. Een ontbrekend extent kan veroorzaakt zijn door een defect RAID-lid, een beschadigd bestandssysteem op de datastore, een onvolledige kopie of een werkelijk verwijderd object. Eerst wordt vastgesteld op welke laag gegevens ontbreken. Pas daarna kan worden beoordeeld of herstel uit metadata, ongealloceerde ruimte, een back-up of een oudere snapshot technisch zinvol is.

Bij de intake worden daarom geen losse bestanden geselecteerd op basis van hun naam. Een volledige inventaris met directorylijst, export van de VM-configuratie en informatie over het opslagplatform bewaart de relaties. De oorspronkelijke gegevensdrager blijft buiten alle experimenten. Bij netwerktransport worden archieven en hashes gecontroleerd zodat een afgebroken upload niet als oorspronkelijke schade wordt geanalyseerd.

Bewaar namen en mappen exact
Exporteer configuratie en logboeken samen
Controleer kopiehashes vóór analyse

Bestandsrelaties eerst

UUID’s en configuratie koppelen elke extent aan de juiste instantie.

Opslaglaag meewegen

Datastorefouten kunnen hogerop als ontbrekende of corrupte snapshotblokken verschijnen.

Een los diskbestand zonder descriptor, parent en logcontext kan een verkeerde hersteltoestand voorstellen.

Eerste stap

VM-start en automatische consolidatie onmiddellijk stoppen

Elke start van de virtuele machine schrijft nieuwe journalrecords, logregels, tijdelijke bestanden en applicatiegegevens naar de actieve laag. Een database kan hersteltransacties uitvoeren en een besturingssysteem kan updates of schijfcontroles starten. Daardoor verandert precies het materiaal dat nodig is om het incidenttijdstip te reconstrueren. De VM blijft daarom uitgeschakeld totdat alle afhankelijke bestanden veilig zijn gekopieerd.

Automatische snapshotconsolidatie, checkpoint merge of opslagmigratie is eveneens riskant. Wanneer een descriptor naar de verkeerde parent wijst, kan een merge geldige blokken met een onjuiste basis combineren. Het resultaat kan schijnbaar starten, maar bestanden uit verschillende tijdstippen bevatten. Een dergelijke logische vermenging is moeilijker te herkennen dan een duidelijke mountfout en kan een bruikbaar herstelpunt overschrijven.

De veiligste eerste maatregel is de betrokken workload gecontroleerd pauzeren, zonder een nieuwe snapshot te maken. Bewaar alle VM-bestanden samen en registreer welke host, datastore en storagecontroller actief waren. Als live uitschakelen niet mogelijk is, moet de beheerder eerst de bedrijfsimpact en schrijfstroom afwegen; een crash-consistente kopie is niet automatisch applicatieconsistent, maar voorkomt wel ongecontroleerde verdere wijziging.

Ook back-upsoftware en replicatie kunnen de keten wijzigen of checkpoints opruimen. Taken worden niet blind hervat zolang hun effect onbekend is. Beschikbare back-ups blijven wel bewaard als afzonderlijke bron. Hun catalogus, retentie en laatste geslaagde run helpen bepalen of een snelle restore volstaat of dat unieke, recentere blokken uit de beschadigde keten nodig zijn.

Forceer geen snapshotconsolidatie op de originele datastore
Bewaar descriptors, delta’s, extents en parents met hun namen
Start de virtuele machine niet vóór de kopie

Techniek

Parent-, child- en snapshotrelaties technisch ordenen

Een volume dat kan worden aangekoppeld, bewijst niet dat de juiste keten is gekozen: delta- en differencingdisks bevatten alleen gewijzigde blokken en zijn zonder de juiste voorganger onvolledig. De reconstructie vergelijkt descriptorvelden, parentlocators, CID’s, UUID’s, geometrie, virtual size en loggegevens. Tijdstempels ondersteunen de analyse, maar beslissen nooit alleen: een kopieeractie of restore kan ze wijzigen zonder dat de inhoud een nieuw herstelpunt vormt.

Een geldige keten moet niet alleen technisch openen, maar ook chronologisch coherent zijn. Voor elk blok wordt bepaald uit welke laag de nieuwste geldige versie komt. Bij vertakkingen worden alternatieve ketens als afzonderlijke hypothesen opgebouwd. Zo kan een beheerder een toestand vóór corruptie vergelijken met een recentere toestand waarin nog belangrijke transacties staan, zonder de bronbestanden te hernoemen of te wijzigen.

Ontbrekende descriptors kunnen soms uit extents, headers en hypervisorlogs worden afgeleid. Dat is geen reden om direct nieuwe metadata in het origineel te schrijven. De afgeleide descriptor wordt op een werkkopie gemaakt en technisch gedocumenteerd. Wanneer een parent werkelijk ontbreekt of deels overschreven is, wordt de verwachte impact per volume en bestand benoemd in plaats van een volledige keten te veronderstellen.

Elke gereconstrueerde koppeling krijgt een herleidbare onderbouwing: welk veld, logrecord of blokpatroon de relatie ondersteunt en welke onzekerheid overblijft. Die documentatie is belangrijk wanneer twee snapshots dezelfde virtuele grootte hebben of een gekloonde VM identieke basiskenmerken bevat. Zonder herleidbare broninformatie kan een later aangekoppeld volume niet aantonen dat de juiste productie-instantie is hersteld.

Vergelijk UUID, CID en geometrie
Test vertakkingen op aparte kopieën
Documenteer bewijs per koppeling

Tijdstempel als steunbewijs

Kopieën en restores kunnen datums veranderen zonder nieuwe inhoud.

Vertakkingen apart houden

Elke mogelijke keten krijgt een eigen reproduceerbare werkkopie.

Een kleine delta bevat alleen wijzigingen; een verkeerde basis kan gegevens uit verschillende tijdstippen combineren.

Diagnose

Thin provisioning en sparse blokken juist interpreteren

Een thin-provisioned disk presenteert meer logische capaciteit dan er fysiek is toegewezen. Niet-gealloceerde blokken zijn normaal en betekenen niet dat gegevens verloren zijn. VMDK grain tables, VHDX block allocation tables en QCOW2 L1- en L2-tabellen bepalen welke fysieke blokken bij een logisch adres horen. Beschadiging van die metadata kan bestaande inhoud echter ten onrechte als leeg voorstellen.

De diagnose vergelijkt allocatiemappen met bestandsgrootte, extents en het onderliggende datastorebestandssysteem. Bij een beschadigde RAID of NAS worden eerst stabiele images van de leden gemaakt en wordt de opslaggeometrie gereconstrueerd; bij een SAN worden de betrokken LUN-, pool- en arraylagen afzonderlijk veiliggesteld en gedocumenteerd. Anders kan een fout op arrayniveau worden aangezien voor een probleem in de virtuele disk en worden dezelfde ontbrekende blokken op meerdere lagen verkeerd geïnterpreteerd.

Zeroed blocks, discard en TRIM vragen extra voorzichtigheid. Een nulwaarde kan bewust zijn aangemaakt, nooit toegewezen zijn geweest of na een verwijderactie zijn vrijgegeven. Alleen context uit allocatiemetadata, snapshots en het gastbestandssysteem maakt dat onderscheid aannemelijk. Fysiek overschreven of door de storagecontroller definitief vrijgegeven blokken kunnen niet door een logische reconstructie worden teruggebracht.

Bij overcommit kan een volle datastore bovendien nieuwe snapshots of consolidaties hebben afgebroken. Vrije capaciteit, alarms en thin-poolmetadata worden daarom naast de virtuele disk gelegd. Een uitbreiding van het volume achteraf wordt niet op de bron uitgevoerd: eerst moet duidelijk zijn welke tabellen inconsistent zijn en of bijkomende allocatie oude, nog herstelbare datastoreblokken zou hergebruiken.

Reconstructie

Het gastvolume pas openen na ketenreconstructie

Alleen-lezen reconstructie komt vóór bestandssysteemherstel, want een virtuele disk kan mounten terwijl blokken uit verschillende snapshots zijn gecombineerd. Zichtbare mappen bewijzen dan geen consistente toestand. Eerst wordt een alleen-lezen representatie van de gekozen keten opgebouwd. Daarna worden partitietabellen, LVM, Storage Spaces, NTFS, ReFS, ext, XFS of andere gaststructuren onderzocht zonder een reparatieprogramma tegen het gereconstrueerde bronbeeld te laten schrijven.

Bestandssysteemmetadata wordt op meerdere niveaus vergeleken. Bootsectoren, superblocks, allocation maps, directoryrecords en journals tonen of de structuur bij hetzelfde tijdstip past. Een journal replay kan op een afgeleide kopie worden getest, maar het ongewijzigde ketenbeeld blijft behouden. Zo kan een reparatie-effect worden geëvalueerd en teruggedraaid zonder een tweede acquisitie van de datastore.

Encryptie verandert de volgorde van werken. BitLocker, LUKS of applicatie-encryptie vereist geldige sleutels, recoverymateriaal en de juiste virtuele beveiligingscontext. Een ontbrekende vTPM-state of sleutel kan leesbare blokken toch onbruikbaar maken. Datastrophe omzeilt die beveiliging niet; verstrekte, bevoegde toegangsgegevens worden alleen op de werkkopie gebruikt en afzonderlijk van de herstelde data behandeld.

Daarna worden bestanden geëxporteerd naar een gezond doelvolume in plaats van het gereconstrueerde gastvolume als productiebron te gebruiken. Rechten, lange paden, sparse files en extended attributes worden waar relevant behouden. De exportlog vermeldt leesfouten en overgeslagen objecten, zodat een beheerder weet welke gegevens werkelijk zijn gekopieerd en welke alleen in de directorystructuur zichtbaar waren.

Bouw eerst een consistente keten
Bewaar het eerste image ongewijzigd
Exporteer naar nieuwe gezonde opslag

De nieuwste wijzigingsdatum bepaalt de keten niet

UUID’s, parentverwijzingen, volgorde en hypervisorlogs tonen de afhankelijkheid. Bestandsgrootte of datum alleen is onvoldoende.

Encryptie blijft leidend

Geldige sleutels en beveiligingscontext blijven noodzakelijk voor logische toegang.

Reparaties op een afgeleide kopie blijven omkeerbaar en beschermen het enige samenhangende ketenbeeld.

Prioriteit

Databanken en diensten controleren boven het bestandsniveau

Een bootende VM is geen voldoende bewijs van herstel. Databanken, directoryservices, mailservers en bedrijfsapplicaties zijn afhankelijk van samenhang tussen data-, log-, index- en configuratiebestanden. De controle bepaalt eerst welk applicatietijdstip gewenst is en of de beschikbare logketen daarbij aansluit. Pas daarna wordt een testinstantie in een geïsoleerde omgeving overwogen.

Waar het formaat dit toelaat, krijgt een gecontroleerde export de voorkeur boven het terug in productie brengen van de volledige beschadigde machine. Tabellen, mailboxen of projectgegevens kunnen dan op inhoud en telling worden gecontroleerd. Een export voorkomt ook dat onbekende services, geplande taken of beschadigde systeemcomponenten tijdens de validatie nieuwe wijzigingen uitvoeren op de gereconstrueerde kopie.

Validatie gebruikt afgesproken prioriteiten: bijvoorbeeld recente transacties, specifieke mailboxen, een ERP-boekjaar of configuraties van een domeincontroller. Steekproeven worden verspreid over oude en nieuwe datagebieden. Wanneer alleen een bepaalde database, periode of directory betrouwbaar is, wordt die grens expliciet opgenomen in het resultaat; bestandsgrootte en foutloze start alleen zijn onvoldoende.

Authenticatie en netwerkverbindingen blijven tijdens tests beperkt. Een gekopieerde domeincontroller of server mag niet ongecontroleerd met de productieomgeving communiceren, omdat dubbele identiteiten en automatische synchronisatie nieuwe schade kunnen veroorzaken. Testnetwerk, snapshots van de werkkopie en duidelijke stopvoorwaarden maken de validatie reproduceerbaar zonder dat het oorspronkelijke incident zich buiten het laboratorium uitbreidt.

Grenzen

Het bruikbare herstelpunt kiezen volgens het incident

De recentste snapshot is niet automatisch de beste bron wanneer ransomware, foutieve updates of databasecorruptie al in meerdere delta’s aanwezig zijn. Incidenttijd, monitoring, back-uplogs en de laatste bekende correcte transactie helpen een functioneel herstelpunt kiezen. De analyse onderscheidt een technisch consistente toestand van een toestand die ook voor de organisatie bruikbaar is.

Meerdere kandidaten kunnen op afzonderlijke kopieën worden gemonteerd en vergeleken. Bestandsdatums, applicatielogs en aantallen records tonen welke wijzigingen tussen twee punten liggen. Deze vergelijking voorkomt dat een oudere maar schone toestand wordt gekozen terwijl cruciale recente data nog selectief uit een latere laag kan worden geëxporteerd. De uiteindelijke combinatie gebeurt alleen wanneer de toepassing dat veilig ondersteunt.

Herstelbaarheid kent harde grenzen. Ontbrekende parentblokken, overschreven extents, onbeschikbare encryptiesleutels of beschadigde allocatiemappen kunnen permanente hiaten veroorzaken. Ook een succesvolle ketenreconstructie garandeert geen transactiesamenhang. Het rapport beschrijft daarom gebruikte bronnen, gekozen tijdstip, toegepaste reconstructie en resterende onzekerheden, zodat de beheerder het resultaat verantwoord kan inzetten.

Wanneer twee herstelpunten elk unieke waarde hebben, worden zij niet stilzwijgend samengevoegd. De opdrachtgever ontvangt aparte exports of een duidelijk beschreven selectieve migratie. Dat beschermt audittrails en voorkomt dat oude configuratie met nieuwe transacties wordt vermengd. Een expliciete keuze is vooral belangrijk bij boekhouding, mail, directoryservices en systemen met wettelijke bewaartermijnen.

Parent-childafhankelijkheden gereconstrueerd
Consistent tijdstip op werkkopie opgebouwd
Gastbestanden en toepassingen inhoudelijk getest

Incidenttijd als anker

Monitoring en transacties begrenzen de relevante snapshotperiode nauwkeurig.

Varianten niet vermengen

Afzonderlijke exports bewaren herleidbaarheid en voorkomen stille tijdsprongen.

Technische consistentie en bedrijfswaarde worden apart beoordeeld voordat één herstelpunt wordt gekozen.

Vervolg

Virtuele disk verbinden met RAID en serverlaag

Staat de datastore op een defecte array, dan begint het traject bij RAID- en NAS-dataherstel. Eerst worden de fysieke leden veilig gekopieerd en stripevolgorde, pariteit en volumes herbouwd. Pas op die gestabiliseerde laag kan de VMDK-, VHDX- of QCOW2-keten betrouwbaar worden geïnterpreteerd. Een foutieve arraygeometrie vervormt immers elk hoger bestandssysteem.

Voor een beschadigd besturingssysteem, mailplatform of databank sluit de analyse aan op dataherstel van servers. Die pagina behandelt applicatieconsistentie, logketens en gecontroleerde exports. De virtuele-diskdiagnose blijft gericht op containers, snapshots en gastvolumes; zo ontstaat geen dubbel werk en blijft duidelijk op welke technische laag een bevinding is vastgesteld.

Voor een eerste beoordeling zijn hypervisor en versie, diskformaat, foutmelding, incidenttijd en een volledige directorylijst nodig. Vermeld migraties, mislukte consolidaties, storage-uitval, encryptie en eerdere herstelpogingen. Stuur geen losse delta zonder parentbestanden en wijzig geen namen om uploadproblemen te omzeilen. Een samenhangende, onveranderde set verkort de analyse en beschermt alternatieve herstelroutes.

De oplevering kan bestaan uit gevalideerde bestanden, een applicatie-export of een testbare kopie van de VM, afhankelijk van consistentie en gebruiksdoel. Zij gaat naar nieuwe opslag; de beschadigde datastore wordt niet opnieuw in gebruik genomen. Bij overdracht worden structuur, gekozen tijdstip, controles en bekende hiaten vastgelegd zodat de heringebruikname planbaar blijft. Via offerte aanvragen worden platform, ketenonderdelen en prioritaire diensten vooraf afgebakend.

FAQ

Veelgestelde vragen

Welke bestanden zijn nodig voor een VMDK- of VHDX-reconstructie?

Verzamel descriptor, extents, snapshot- en deltadelen, VM-configuratie en beschikbare hypervisorlogs. Bewaar oorspronkelijke namen, paden en directorystructuur. Parent-childrelaties worden vastgesteld met UUID’s, CID’s, headers, geometrie en logcontext; wijzigingsdatums ondersteunen dat onderzoek, maar volstaan niet om de keten te bepalen.

Waarom mag de beschadigde virtuele machine niet meer starten of consolideren?

Een start schrijft journals, logs en applicatiegegevens en kan een nieuwe delta maken. Consolidatie verandert de keten en kan bij een verkeerde parentrelatie geldige blokken vermengen. Daarom wordt de workload gepauzeerd, de volledige datastore onveranderd gekopieerd en worden afhankelijkheden uitsluitend op afzonderlijke werkkopieën getest.

Wat betekent dataherstel bij een thin-provisioned virtuele schijf?

Een thin disk bevat alleen fysiek toegewezen blokken; niet-aanwezige ruimte kan dus normaal zijn. Allocatiemappen, extents, datastoremetadata en onderliggende storage worden samen onderzocht. Zo worden nooit toegewezen gebieden onderscheiden van beschadigde metadata, ontbrekende extents, discard of daadwerkelijk verloren gegevens.

Hoe wordt een databank uit een herstelde virtuele machine gevalideerd?

Een mountbaar volume en zichtbare bestanden volstaan niet. Data-, log-, index- en configuratiebestanden moeten bij hetzelfde tijdstip passen. Waar het formaat dit toelaat, volgt een gecontroleerde export of een geïsoleerde toepassingstest op de werkkopie, met steekproeven uit afgesproken kritieke tabellen en periodes.

Opslagmedia

Andere expertises

Diagnose

Twijfelt u over een opslagmedium of defect?

Datastrophe kwalificeert het risico voor elke ingreep en geeft aan welke aanpak het meest voorzichtig is.

Diagnose aanvragen