Een virtuele machine werd verwijderd. Is die nog terug te halen?

Vaak wel, zolang de vrijgekomen ruimte nog niet overschreven werd. Stop meteen met schrijven naar de datastore, maak geen nieuwe virtuele machines aan en vraag een analyse aan.

Onze snapshotketen is beschadigd en de VM start niet meer. Wat nu?

Voeg geen snapshots samen en verwijder er geen. De keten opnieuw opbouwen kan de laatste toestand terugbrengen, maar alleen zolang alle schakels er nog zijn.

Het volume gebruikt deduplicatie en de bestanden openen niet meer. Zijn ze weg?

Meestal niet. De inhoud zit in de chunk store; wat beschadigd is, zijn vaak de verwijzingen ernaar. Laat geen opschoning of andere onderhoudstaken lopen, want die kunnen chunks definitief verwijderen.

Kunnen jullie een Exchange- of SQL-databank herstellen die in een virtuele machine stond?

Ja. We werken de lagen af tot aan de databank en controleren of die weer opent. Laat vooraf geen herstelprogramma's op de databank lopen; die kunnen beschadigde pagina's definitief weggooien.

Wat is het verschil met jullie drie processen voor grote volumes?

De drie processen gaan over de omvang: ze maken het mogelijk om volumes van honderden terabytes te verwerken. Meerlaagse recuperatie gaat over de opbouw: meerdere lagen boven elkaar. In grote omgevingen komen beide vaak samen voor.

In welke vorm krijgen we de gegevens terug?

Dat kiest u: als losse bestanden, als virtuele schijf die u opnieuw koppelt aan uw hypervisor, of als databank die u opnieuw kunt aankoppelen.

Kunnen jullie beschadigde Veeam-back-ups herstellen?

Vaak wel. Staan de back-upbestanden op een defecte opslag, dan halen we eerst die opslag terug. Zijn de back-upbestanden zelf beschadigd, dan maken we gebruik van de redundantie die erin zit, en waar nodig werken we samen met Veeam. Vermeld de versie en, bij versleutelde back-ups, het wachtwoord.

Data Recovery • Datarecuperatie • We zullen uw verloren gegevens herstellen!

Wat is een meerlaagse opstelling?

In een moderne serveromgeving is elke laag een container voor de volgende: de RAID levert een volume, het volume krijgt een partitionering en een bestandssysteem, op dat bestandssysteem staan virtuele schijven, in die virtuele schijven zit opnieuw een bestandssysteem, en daarop staan de bestanden van een applicatie, zoals een Exchange- of SQL-databank.

Elke laag interpreteert de bytes van de laag eronder. Raakt één laag beschadigd, dan wordt alles erboven onleesbaar, ook al staan de gegevens zelf er nog volledig. Het gaat er dan om de beschadigde laag opnieuw op te bouwen, zodat de lagen erboven weer kloppen.

Een beschadigde laag betekent zelden dat de gegevens erboven verloren zijn. Meestal is de sleutel om ze te lezen kwijt, niet de inhoud.

De lagen, van onder naar boven

Laag	Voorbeelden	Wat er vaak misgaat
Opslag en RAID	Schijven, RAID-controller, NAS, SAN	Defecte schijven, verloren RAID-configuratie
Partitionering	MBR, GPT, LVM, Storage Spaces	Overschreven partitietabel, per ongeluk geïnitialiseerde schijf
Bestandssysteem (native file system)	NTFS, ReFS, ext4, XFS, ZFS, Btrfs, VMFS	Beschadigde metadata, formattering, mislukte controle
Deduplicatie (deduplication)	Windows Server-deduplicatie, ZFS-dedup, back-upappliances	Beschadigde chunk store of index
Virtualisatie	VMware vSphere, Hyper-V, Proxmox en KVM	Verwijderde virtuele machine, losgeraakte snapshots
Virtuele schijf (virtual disk image)	VMDK, VHDX, qcow2, raw	Versnipperd over de datastore, beschadigde header of blokkentabel
Gastbestandssysteem (guest file system)	NTFS, ext4, XFS binnen de virtuele machine	Dezelfde problemen als bij elk bestandssysteem
Applicatie	Exchange (ESE), SQL Server, Oracle, mailarchieven	Beschadigde pagina's, ontbrekende logbestanden
Back-up	Veeam® (.vbk, .vib, .vrb) en andere back-upsoftware	Beschadigde back-upketen, back-upbestanden op een defecte opslag

Technisch: hoe virtuele schijven hun blokken bijhouden

Een virtuele schijf die niet vooraf volledig toegewezen is (thin provisioned, sparse), bewaart een tabel die aangeeft waar elk blok van de virtuele schijf in het bestand staat: bij VMDK de grain directory en grain tables, bij VHDX de Block Allocation Table (BAT), bij qcow2 de L1- en L2-tabellen.

Snapshots en differencing disks (VMware delta-bestanden, Hyper-V .avhdx) vormen een keten: elk bestand bevat alleen de gewijzigde blokken en verwijst naar zijn ouder. Is een schakel of de verwijzing ernaar beschadigd, dan moet de keten opnieuw opgebouwd worden om de actuele toestand van de schijf te krijgen.

Het principe: de andere lagen vertellen wat er ontbreekt

Elke laag bevat, bewust of onbewust, informatie over de lagen eromheen. Die gebruiken we in drie richtingen:

Van boven naar onder. De inhoud van een hogere laag verraadt hoe een lagere laag in elkaar zat. Een bestand in de virtuele machine dat over twee fragmenten van de virtuele schijf loopt, bevestigt dat die fragmenten na elkaar horen; zo kan een versnipperde virtuele schijf in de juiste volgorde gelegd worden, ook als de blokkentabel weg is. En het bestandssysteem binnen een partitie vermeldt zijn eigen grootte, waaruit volgt waar de partitie lag, ook als de partitietabel overschreven werd.
Van onder naar boven. Een intacte lagere laag bakent de zoektocht in de hogere af. Weet het bestandssysteem van de datastore nog welke blokken bij welke virtuele schijf horen, dan zoeken we de structuren van een beschadigd gastbestandssysteem alleen in die blokken, en in de juiste volgorde.
Binnen de laag zelf. Veel formaten zijn opgebouwd uit blokken of pagina's met een vaste grootte en een eigen kenmerk of controlesom (checksum). Een databankpagina van SQL Server vermeldt bijvoorbeeld haar eigen paginanummer. Losse stukken kunnen zo herkend, gecontroleerd en in volgorde gelegd worden.

Technisch: voorbeelden van reservekopieën en kenmerken

GPT bewaart een reservekopie van de header en de partitietabel aan het einde van de schijf. NTFS houdt een kopie van de bootsector bij aan het einde van het volume, en een gedeeltelijke kopie van de MFT (MFTMirr). ext4 en XFS bewaren kopieën van hun superblock verspreid over het volume.

SQL Server werkt met pagina's van 8 KB, met in de header het bestands- en paginanummer. Exchange (ESE) werkt sinds Exchange 2010 met pagina's van 32 KB, elk met een eigen controlesom. Zulke kenmerken maken het mogelijk om pagina's terug te vinden tussen andere gegevens.

Deduplicatie: een laag die alles versnippert

Deduplicatie (deduplication) slaat elk uniek stuk gegevens (chunk) maar één keer op. Een bestand is dan geen doorlopende reeks blokken meer, maar een lijst van verwijzingen naar chunks in een gemeenschappelijke opslag (chunk store). Bij Windows Server-deduplicatie blijven de bestanden zichtbaar als verwijzingen (reparse points), terwijl de inhoud in de chunk store zit.

Raakt de index of de chunk store beschadigd, dan lijken de bestanden er nog te staan, maar openen ze niet. Tegelijk bevat de chunk store de volledige inhoud. De laag erboven, bijvoorbeeld een virtuele schijf met een herkenbare structuur, helpt dan om de chunks weer in de juiste volgorde te zetten.

Back-ups als extra laag

Vaak is de back-up zelf de laatste laag die telt: de back-upbestanden van Veeam®, Backup Exec, Macrium Reflect of andere software staan op een NAS, een RAID of een gededupliceerd volume dat uitviel. Dan halen we eerst de opslag terug, daarna de back-upbestanden, en pas dan de gegevens in die back-ups, ook als de back-upbestanden zelf beschadigd zijn.

Alles over het herstel van ontoegankelijke back-ups →

Scenario's uit de praktijk

Verwijderde virtuele machine

Een virtuele machine werd verwijderd van een VMFS-datastore. De ruimte is vrijgegeven, maar de blokken van de virtuele schijf staan er vaak nog; met de structuur van het gastbestandssysteem worden ze teruggevonden en samengevoegd.

Losgeraakte snapshotketen

Een Hyper-V- of VMware-omgeving met snapshots waarvan een schakel beschadigd is. De virtuele machine start niet meer; door de keten opnieuw op te bouwen komt de laatste toestand terug.

Virtuele Exchange-server

RAID, VMFS, VMDK, NTFS en een Exchange-databank boven elkaar. Eén beschadigde laag volstaat om de mailbox onbereikbaar te maken; de andere lagen helpen om ze te herstellen, tot de databank weer leesbaar is.

Waarom standaardsoftware hier vastloopt

Gewone recuperatiesoftware werkt met één laag tegelijk en gaat ervan uit dat de lagen eronder in orde zijn: een bestandssysteemtool verwacht een correcte partitie, een VMDK-tool een leesbare datastore, een databanktool een intacte virtuele schijf. In een meerlaagse opstelling met schade op meer dan één niveau klopt die veronderstelling niet meer.

Daarom kijken we naar de hele stapel tegelijk, en bepalen we per laag welke informatie uit de andere lagen nodig is om ze te reconstrueren.

Wat u best doet

Doe dit wel

Stop de virtuele machines en alles wat naar de betrokken opslag schrijft.
Bewaar de configuratie: VM-instellingen (.vmx of de Hyper-V-configuratie), een overzicht van de datastores en de snapshots.
Noteer de volledige opbouw: RAID, volumes, deduplicatie, virtualisatie, applicaties.
Bewaar logbestanden van de hypervisor, de opslag en de applicatie.

Doe dit niet

Geen snapshots samenvoegen (consolidate) of verwijderen.
Geen datastore of volume opnieuw aanmaken of formatteren.
Geen onderhoudstaken van de deduplicatie laten lopen, zoals opschoning (garbage collection).
Geen herstelprogramma's binnen de virtuele machine of op de databank laten lopen, zoals chkdsk of eseutil /p.

Hoe een dossier verloopt

Analyse per laag. We brengen de volledige opbouw in kaart en bepalen welke lagen beschadigd zijn.
Kopieën. Van elke schijf maken we een volledige kopie; fysiek beschadigde schijven herstellen we eerst in ons Class 1 labo.
Reconstructie. We beginnen bij de laagste beschadigde laag en gebruiken de informatie uit de andere lagen om ze op te bouwen, laag per laag, tot aan de applicatie.
Controle op applicatieniveau. Een databank moet niet alleen terug zijn, maar ook openen. We controleren het resultaat op het niveau waarop u het gebruikt.
Levering. Als bestanden, als virtuele schijf die u opnieuw kunt koppelen, of als databank. U ziet het resultaat vóór u betaalt.

Bij zeer grote volumes combineren we dit met onze aanpak in drie processen.

Meer over de recuperatie van zeer grote volumes →

Meerlaagse recuperatie (multi-layer recovery)