The application server stops responding, the hypervisor flags the virtual machine as failed, and it simply won’t restart. Look closer, and the SQL Server database behind your ERP, CRM, or line-of-business app has vanished outright. This scenario, increasingly common in organizations running MSSQL on virtualized infrastructure, throws even seasoned system administrators: the usual tools come up empty, and the database appears to have evaporated even though nothing points to a classic hardware failure.
Why an MSSQL database can disappear when the VM gets corrupted
A SQL Server database almost always runs on a virtual machine, whether on VMware, Hyper-V, or Proxmox. That VM sits on a virtual disk (a VMDK or VHDX file, depending on the hypervisor), and the virtual disk itself is stored on physical infrastructure: a NAS, a SAN array, or a local server. Three layers stack up between your database and the actual hardware, and any one of them can be where corruption starts.
When the underlying physical storage becomes corrupted or fills up abruptly (a NAS hitting 100% capacity, a failing RAID controller, a write interrupted mid-replication), it’s not just the database file that takes the hit. The VM’s own file system, usually NTFS, can be damaged at the structural level.
The MFT’s central role
On an NTFS volume, the Master File Table (MFT) is the structure that indexes every file on the volume: its location, its size, its attributes. Without a usable MFT, the operating system no longer knows where files live, even though the data is still physically present on the disk. In practice, that means no standard access to your database’s .mdf and .ldf files: Windows simply can’t see them anymore, and SQL Server obviously can’t mount a database whose files it can’t locate.
Why standard SQL recovery steps won’t cut it here
A DBA facing this kind of incident is often left at a loss, and understandably so: the tools they rely on day to day simply have no purchase on this type of failure. The natural instinct is to run DBCC CHECKDB to diagnose internal database corruption, or to restore the latest backup. Both approaches rest on an assumption that doesn’t hold here: they assume the database is reachable but “corrupted at the SQL level”, meaning its files exist and are readable, but their content is the problem.
In this case, though, the problem sits one layer down: it isn’t the database that’s corrupted, it’s the file system holding it that has disappeared. No SQL repair tool, however capable, can act on files the operating system itself can no longer reach. Trying to restore a backup onto a volume that’s no longer responding, or running an application-level repair on a database that no longer resolves, only burns precious time without addressing the actual issue.
What to do, and above all what not to do, right away
With this kind of incident, the first few minutes matter, but not in the way most people assume. The priority isn’t to act fast to “fix” things, it’s to avoid doing anything that could make the situation worse.
- Shut down the affected virtualization host immediately. Continuing to write to the storage, including through automatic mechanisms like TRIM or UNMAP on SSDs, risks permanently erasing data that’s still present but that the system can no longer index.
- Don’t run a generic NTFS repair such as chkdsk on the affected volume. Much like a premature RAID rebuild, an automatic repair of this kind can overwrite structures and destroy the last recoverable traces of your data.
- Don’t try to remount the virtual disk in write mode “just to see if it comes back”. Every attempt like this lowers the odds of a full recovery down the line.
- Get a professional assessment before any further manipulation. Most data recovery labs, Chronodisk included, offer a free initial diagnostic to precisely assess the state of the volume before anything else is attempted.
These precautions apply whether your infrastructure runs on a classic RAID volume or a virtual machine: either way, the absolute priority is preserving the current state of the media, however degraded, rather than piling on attempts that complicate the reconstruction work.
What a professional recovery actually involves in this scenario
Without a usable NTFS structure or MFT, there’s no simple “restore” available. Recovery requires manual, low-level reconstruction of the disk: identifying, block by block, the regions belonging to the database files based on signatures and patterns specific to the SQL Server MDF and LDF formats, then rebuilding a usable table structure from those recovered fragments.
This work bears no resemblance to a standard backup restore. It demands a deep understanding of both the internal SQL Server database format and the mechanics of virtualized file systems, which is exactly why this type of case can’t be resolved with standard SQL tools, nor in a matter of hours. It’s meticulous reverse-engineering work, shaped by the actual state of the media and the volume of data that can realistically be recovered.
Chronodisk handles this type of corruption, whether it affects physical RAID volumes or virtual machines running on VMware, Hyper-V, or Proxmox. When no physical hardware failure is involved (no drive that won’t power up, no abnormal noise signaling a mechanical fault), the intervention can often be carried out remotely, saving valuable time compared to a physical transfer of the equipment. In every case, an upfront diagnostic determines whether the MFT is partially recoverable, whether a signature-based reconstruction is needed, and what volume of data can reasonably be restored.
If your SQL Server database has become inaccessible following VM corruption, the first thing to do is resist the urge to “just try it one more time”. Every uncontrolled manipulation lowers the chances of recovery. A professional diagnostic brings clarity quickly, without risking further damage to an already difficult situation.