A virtual machine is not stored in a partition like a conventional system: it is one large file sitting on a disk, almost always a server in a RAID array. When the hypervisor crashes, the RAID goes down or this file becomes corrupted, the data is not necessarily lost, but two layers have to be rebuilt one after the other: first locate the virtual machine file, then rebuild the system inside it. The right reflex is the same as for any server: shut everything down, recreate nothing, and hand the disks to a lab.

What follows explains what virtualization really is, how a virtualized environment fails, and why certain repair attempts doom the data for good.

Virtualization made clear

To virtualize is to run a complete machine, with its own operating system, inside another. This virtual machine is not part of the disk's partitioning: it is stored in one large file, which allows it to be moved from one server to another like a simple document.

There are two ways to virtualize, and the distinction matters. The first is what is known as desktop virtualization, with software such as VMware Workstation or Oracle VirtualBox, installed inside an existing operating system, for example Windows. This software runs a second system in a window. The layers are then stacked: the virtual machine communicates with the virtualization software, which talks to Windows, which finally accesses the real hardware, the motherboard, the network card and the rest. It is handy for testing or running two systems side by side on a workstation, but it is not what is used in production.

For a corporate server, a hypervisor is used: VMware ESXi, Microsoft Hyper-V or Proxmox, the latter also existing in a community version that is open source and free. Here, there is no large operating system on top of which software would be installed. The hypervisor is itself a small, lightweight piece of software, placed directly on the machine, and it is on it that real virtual machines are installed, running Windows, Linux, macOS or lighter systems.

The benefit is both economic and practical. A powerful physical machine is almost never used to its full capacity at all times. Rather than letting that power lie idle, two, three or four virtualized servers are run on a single machine, sharing its resources. Better still, each VM can be allocated a number of processors and an amount of memory, then increased on demand if a server comes under load. This flexibility is what makes virtualization so successful, and it is also what concentrates a great deal of critical data on a single machine.

Desktop virtualization versus hypervisor: the difference

Criterion	Desktop virtualization	Hypervisor (server)
Examples	VMware Workstation, Oracle VirtualBox	VMware ESXi, Microsoft Hyper-V, Proxmox
Installation	Inside an existing system (Windows)	Directly on the machine
Stacked layers	VM, software, Windows, hardware	VM, hypervisor, hardware
Typical use	Testing, running two systems side by side	Production servers
Storage	A file on the workstation's disk	A file on a datastore, almost always in a RAID array

How a virtualized environment fails

Since everything rests on a single physical machine and a software stack, there are multiple points of failure. Here are the ones we see.

Failure	Consequence
Hypervisor crashes	No more access to the virtual machine files
Server RAID goes down	The VM storage becomes inaccessible
Corrupted datastore	The space hosting the VMs is no longer readable
Corrupted VMDK or VHDX file	Like a failure of the VM's partition
Damaged partition inside the VM	The VM no longer boots

The hypervisor may crash and refuse to restart: access to the files containing the various virtual machines is then lost. The server RAID may go down, and since virtualization servers almost always run on a RAID, this is a classic. The datastore, the space that hosts the VMs and describes their organization, may become corrupted. The virtual machine file itself, a VMDK on VMware, a VHDX on Hyper-V, may be damaged, which amounts to a failure of the VM's partition. Finally, the failure may lie inside the virtual machine itself, in its file system, preventing it from booting.

In practice, the two most common cases are the RAID going down and a faulty hypervisor. The rest are added to these or stem from them.

The snapshot trap

A very widespread confusion is costly: many regard a snapshot as a backup. That is false, and dangerous.

A snapshot is merely a differential snapshot: it records the changes that have occurred since a given point, and it depends entirely on the parent disk it relies on. If that parent disk is lost or corrupted, or if the chain of snapshots is broken, the snapshot on its own is no longer worth anything. Worse, a long chain of snapshots that have never been consolidated weakens the whole and complicates any recovery. A snapshot is useful for rolling back quickly, but it in no way replaces a genuine, independent backup.

The double layer: locate the file, then its content

This is what sets the recovery of a virtualized server apart from that of an ordinary disk: there are two layers to rebuild, one after the other.

The first consists of locating the virtual machine file, the VMDK or the VHDX, wherever it is, that is to say most often on a failed RAID. The RAID must therefore first be rebuilt to access the datastore, then the virtualization files extracted from it. The second layer consists of opening this file and rebuilding the system it contains, with its own file system and its data.

The client's need then guides the work. Some want to recover the virtual files themselves, in order to bring them back up as they are on another server. Others no longer have any use for virtualization: they want to migrate to a more recent Windows Server, and it is not the VMDK that interests them, but its content. In that case, we export the VM file, then analyze its content to return separately the files, databases or mail systems it contained.

Our method does not vary. As with any recovery, we begin by freezing the state: no direct action on the originals, but bit-for-bit safety copies, on which alone we then work. We rebuild the RAID on the fly from these copies, locate the virtualization files, export them, then rebuild their content. We do not, moreover, need the entire server: everything is reworked virtually, from the disks.

The mistakes that make things worse, and prevention

Faced with a failed virtualized environment, persistence is the worst enemy. Recreating a datastore, generating new snapshots, reinstalling the hypervisor on the disks, or launching a reckless RAID rebuild: each of these operations writes to the storage and can permanently destroy data that is still recoverable. The more you try to repair blindly yourself, the more you reduce the chances. The right reflex is to shut down the server and hand the disks to a lab before any other attempt.

On the prevention side, virtualization does not exempt you from backing up, quite the opposite, since it concentrates several servers on a single machine. Certain solutions, such as Proxmox, can perform genuine backups to a remote NAS, which is a real plus. But even an automated backup does not protect against everything, since ransomware can, for example, reach the VM files just like the rest. A virtual machine sitting on a RAID is not a backup: here too, you need an independent copy kept elsewhere.

What to remember

A virtual machine is a file, generally stored on a server in a RAID array, and its recovery plays out on two levels: locate the VMDK or VHDX file, then rebuild the system and the data it contains. The most common failures come from the RAID going down or the hypervisor crashing, and a snapshot, often mistaken for a backup, is not one.

In the event of a problem, the rule is that of any serious server incident: recreate nothing, reinstall nothing, shut down and hand over the disks. A lab works on copies, rebuilds the RAID virtually, extracts the VM files and their content, without ever touching the originals. And for the future, a genuine external backup remains the only net that holds.

Frequently asked questions

What exactly is a virtual machine?

It is a complete computer, with its own operating system, running inside another machine. Unlike a conventional system, it does not occupy a partition: it is stored in one large file (a VMDK on VMware, a VHDX on Hyper-V), which makes it possible to move it from one server to another like a document.

Can a snapshot serve as a backup?

No. A snapshot is a differential snapshot that records only the changes since a given point and that depends entirely on the parent disk. If the parent is lost or if the chain of snapshots is broken, the snapshot on its own is no longer worth anything. It is useful for rolling back, but does not replace an independent backup.

What are the most common failures on a virtualized server?

In practice, two dominate: the server RAID going down (virtualization servers almost always run on a RAID) and the hypervisor crashing and refusing to restart. Then come the corrupted datastore, the damaged VMDK or VHDX file, and the partition inside the VM.

Can the data be recovered without the physical server?

Yes. The disks are enough. We make bit-for-bit copies of them, rebuild the RAID virtually from these copies, locate the virtualization files, then rebuild their content. Everything is reworked virtually, without needing the entire machine.

What to do, and above all not to do, when a VM no longer boots?

Do not recreate a datastore, do not generate new snapshots, do not reinstall the hypervisor on the disks and do not launch a reckless RAID rebuild: each of these operations writes to the storage and can destroy data that is still recoverable. The right reflex is to shut down the server and hand the disks to a lab.

Does virtualization exempt you from making backups?

On the contrary. Since it concentrates several servers on a single machine, it increases the risk in the event of a disaster. Solutions such as Proxmox can back up to a remote NAS, but no backup protects against everything (ransomware can reach the VM files). A VM sitting on a RAID is not a backup: you need an independent copy kept elsewhere.