A Windows Server 2019 host running four Hyper-V VMs came back from a power event with two VHDX files that Hyper-V refuses to mount. A Microsoft Exchange 2019 mailbox database went into a dirty shutdown state during backup, and now eseutil /p has completed but users report calendar entries missing and folder hierarchies scrambled. A SQL Server 2022 ERP database sits in Recovery Pending after the underlying RAID 5 array lost a drive during rebuild, and support articles are recommending DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS on the production database. A Windows Server 2022 Storage Spaces file server has its 40 TB ReFS volume mounted as RAW after a Windows Update, and the admins are three days into trying tools to fix it. A domain controller on Storage Spaces detached its virtual disk when the journal SSD wore out, and now Active Directory replication has stopped across the forest.

Windows Server data recovery is not a single problem. It’s a family of workload-specific failures that share a common failure pattern: hardware breaks; the storage substrate on top of the hardware breaks; the filesystem on top of the storage substrate breaks; and the Microsoft workload on top of the filesystem is what the customer actually cares about and what they’re trying to recover. The way each layer fails is different. The way the layers fail together, however, is remarkably consistent, and the recovery pattern that works across them is also consistent.

Gillware handles Windows Server recovery as one integrated engagement rather than four separate ones. When a PowerEdge R730 running Hyper-V loses a RAID 5 array during rebuild and the VMs on it stop mounting, the recovery isn’t just RAID work, and it isn’t just Hyper-V work; it’s both, plus the NTFS or ReFS filesystem on the reconstructed array in between. This page is the top-level entry point for that class of work, linking to the workload-specific pages we’ve built for the individual pieces.

What this hub covers, and what it doesn’t

Windows Server data recovery, as this hub defines it, is Microsoft-workload-specific recovery on top of a working — or recoverable — storage substrate. When the hardware or storage layer needs the primary attention, that work lives on our hardware-vendor and storage pages: Dell server recovery for a PowerEdge or PowerVault, HP server recovery for a ProLiant or MSA, our RAID recovery pages for the array controller, our NAS recovery pages for network storage appliances. When the filesystem layer needs the primary attention — a RAW ReFS volume after a Windows Update, an NTFS master file table failure — that work is on our ReFS and NTFS pages. This page hubs together the workload layer that lives on top of both.

The workloads we cover with dedicated pages:

• Hyper-V data recovery — VHDX files, checkpoint chains (AVHDX), broken virtualization hosts, cluster shared volumes with failed VMs
• Exchange Server data recovery — EDB (Jet database) files, transaction log streams, DAG failures, the aftermath of eseutil /p
• SQL Server data recovery — MDF/NDF/LDF file recovery, Recovery Pending/Suspect/Emergency mode, the aftermath of DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS
• Storage Spaces data recovery — pool metadata, virtual disks, Storage Spaces Direct clusters, journal/cache SSD failures

Two workloads we handle regularly but don’t yet have dedicated pages for — call us and we’ll walk you through the same recovery pattern:

• Active Directory (NTDS.dit corruption, forest-level failures, tombstoned objects, USN rollback)
• Windows Server Backup / VSS (corrupted backup catalog, damaged .vhdx backup files, shadow copy tables that no longer resolve)

Most Windows Server recovery cases involve more than one of these. A domain controller running on a Storage Spaces pool that lost its journal SSD is simultaneously a Storage Spaces case, a filesystem case, and an Active Directory case. We handle the whole chain rather than referring pieces of it to other places.

The Windows Server failure pattern is layered

Every Windows Server workload lives on top of a stack. The workload is what the business cares about. The stack under it is what determines whether recovery is possible.

Layer	Hyper-V	Exchange Server	SQL Server	File Server
Workload	VHDX / AVHDX, checkpoint chain, VM configuration XML. Fails as: broken checkpoint chain, VHDX header corruption, missing differential disk.	EDB (Jet database), E00.log transaction stream, checkpoint file. Fails as: dirty shutdown, missing log range, eseutil /p aftermath.	MDF / NDF (data), LDF (log), sys tables at boot page 9. Fails as: Recovery Pending, Suspect, torn page, DBCC REPAIR aftermath.	Files, folder hierarchy, NTFS ACLs, extended attributes, deduplication chunk store. Fails as: dedupe chunk store damage, symlink corruption.
Filesystem	NTFS or ReFS. Fails as: MFT damage under the VHDX, ReFS integrity stream failure.	NTFS (almost always). Fails as: MFT damage under the EDB, chkdsk aftermath.	NTFS or ReFS. Fails as: MFT damage under the MDF, torn-page loop under ReFS.	NTFS or ReFS. Fails as: RAW volume, refsutil salvage output, ReFS 3.4/3.7 version mismatch.
Storage virtualization	Storage Spaces, hardware RAID, SAN LUN, Cluster Shared Volume. Fails as: pool detached, array offline, CSV in Detached state.	Hardware RAID, SAN LUN, DAG replica volume. Fails as: array offline after multiple drive failures, LUN deleted, DAG replica diverged.	Storage Spaces, iSCSI LUN, hardware RAID, Always On availability replica. Fails as: pool read-only, LUN offline, third-party controller wiped.	Storage Spaces (dominant), sometimes hardware RAID. Fails as: pool metadata damage, virtual disk detached, journal SSD failure.
Hardware	Drives, RAID controller, HBA, backplane. Fails as: multi-drive failure, controller battery expired, backplane connectivity loss.	Drives, controller, SAN fabric. Fails as: multi-drive failure, controller cache lost dirty, SAN path flapping.	Drives, controller, SAN fabric, HBA. Fails as: RAID rebuild during production, SAN LUN accidentally deleted, HBA failed.	Drives, sometimes journal SSDs. Fails as: multiple drive failures, cache tier SSD endurance exhausted.

Reading vertically down any column tells you what fails when a single hardware event happens. A drive fails; the RAID array goes degraded and then offline when a second drive follows; the NTFS or ReFS volume develops metadata damage in the region the failed drives covered; the workload file — whatever it happens to be — breaks in whatever way that workload breaks when the block device under it produces bad reads or is missing entirely. Reading horizontally across the table tells you the shared vocabulary — how similar the recovery pattern is across workloads, and where the workload-specific pieces diverge.

The reason the layered pattern matters is that fix attempts at only one layer routinely make the recovery worse. Running DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS on a SQL Server database whose file lives on a partially-degraded ReFS volume damages both the database and the filesystem, because REPAIR writes to blocks that the underlying volume was already struggling to represent correctly. Running eseutil /p on an Exchange database whose transaction log range is incomplete completes the log truncation and produces a “clean” database that has lost hours or days of committed transactions. Running Reset-PhysicalDisk on a Storage Spaces drive that still holds slabs belonging to a virtual disk destroys the slab data. Every one of these tools is safe in the situation it was designed for; every one is destructive in the situation where multiple layers are already failing.

The recovery pattern that actually works is a bottom-up reconstruction: image the physical drives; reconstruct the storage-virtualization layer (RAID array, Storage Spaces virtual disk, SAN LUN) from the drive images; parse the filesystem on the reconstructed volume; extract the workload files from the filesystem; and hand each workload file to a workload-specific parser that walks the internal structure and produces usable output. This is what we do, and it’s the same shape of work regardless of which specific Windows Server workload is on top.

Hyper-V

Hyper-V is the most common Windows Server workload we recover from, both because Hyper-V hosts are heavily deployed and because Hyper-V is unusually sensitive to storage-substrate failures. A VM’s VHDX file lives on a filesystem that lives on a storage substrate; if any of those layers has a bad day, the VM either won’t start, mounts partway and hangs, or reports its virtual disk chain as broken.

The specific failure patterns: checkpoint chains where an AVHDX file is missing or corrupted; VHDX headers overwritten by a bad shutdown; VMs on Cluster Shared Volumes that detached after a Storage Spaces Direct outage; entire virtualization hosts that came back from a power event with multiple guest VMs unable to boot. Recovery involves reconstructing the storage layer under the VHDX, imaging the VHDX file itself, walking its block allocation tables directly, and producing a mountable output.

For full detail, see our Hyper-V data recovery page.

Exchange Server

Exchange 2016, 2019, and Exchange Server Subscription Edition all use the ESE (Extensible Storage Engine, historically called Jet) database format, with a mailbox database in an EDB file and a stream of transaction logs (E00.log and its numbered predecessors) recording every committed change. The most common recovery scenarios are dirty-shutdown states where the database and logs disagree, missing log ranges after a failed backup truncation, and the aftermath of eseutil /p — the “repair” utility that produces a mountable but often data-lossy database by discarding whatever pages ESE couldn’t reconcile.

Recovery in these cases means parsing the EDB directly at the page level, reading past the damage where possible, correlating the transaction log stream with the database pages to identify what was actually committed, and producing either a mountable EDB or a set of PST exports depending on what the customer needs. DAG (Database Availability Group) failures where multiple replicas diverged add complexity but not new fundamental work.

For full detail, see our Exchange Server data recovery page.

SQL Server

SQL Server on Windows Server — from SQL Server 2016 through SQL Server 2022 — presents a specific class of recovery problems because the MDF/NDF/LDF file layout is intricate and every failure mode has a repair path that Microsoft documents as destructive. Recovery Pending, Suspect, and Emergency modes each mean different things; error codes 823, 824, 825, 5172, and 9002 each point to a different subset of on-disk damage; and the standard remediation for many of them — DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS — is a last resort that deallocates whatever pages the database can’t reconcile, often losing entire tables or ranges of rows in the process.

We recover SQL Server databases when the underlying storage substrate has failed (RAID/Storage Spaces/SAN LUN loss), when a database has gone Suspect from filesystem-layer damage, when a third-party SQL repair tool has run and produced a partial or inconsistent database, when a truncated or missing LDF blocks database recovery, and when ransomware or accidental deletion has removed MDF or LDF files. The work involves parsing the MDF at the page level using our internal storage engine implementation, reading past the damage where possible, reconstructing the boot page and system tables, and producing either a mountable database or table-level exports.

For full detail, see our SQL Server data recovery page.

Storage Spaces

Storage Spaces — and Storage Spaces Direct in the S2D and Azure Stack HCI configurations — is the Microsoft storage-virtualization layer that has quietly replaced dynamic disks and, in many deployments, hardware RAID as the default substrate for Windows Server file servers, Hyper-V hosts, and clustered SQL Server workloads. Its on-disk structure is specific enough that recovery is not just RAID work and not just filesystem work; it’s its own discipline.

Failures that reach us: pools that went read-only after a drive was pulled without being marked Retired; virtual disks that detached after a journal or cache SSD failed; S2D nodes that were rebuilt but whose capacity drives are stuck in “retired, removing from pool” and won’t clear; two-node S2D clusters that lost quorum during an outage; Dirty Region Tracking (DRT) logs that filled during a prolonged node absence; and the aftermath of Reset-PhysicalDisk or Clear-Disk -RemoveData being run against still-active pool members. Recovery is a bottom-up reconstruction: image every drive that was ever a pool member, parse the pool metadata regions across the images to reconstruct the slab allocation table, reassemble the virtual disk slab by slab from the correct drives, and hand the reconstructed virtual disk to the NTFS or ReFS parser above.

For full detail, see our Storage Spaces data recovery page.

Active Directory and Windows Server Backup

Two additional Windows Server workloads we recover from regularly but for which we haven’t yet built dedicated pages.

Active Directory. The AD database (NTDS.dit) is another ESE-format Jet database, closely related to the Exchange EDB in on-disk structure. It fails in the same ways: dirty-shutdown states after a domain controller crash, corruption in specific pages that blocks replication, USN rollback scenarios where a DC came back with a stale copy of the database, tombstoned objects that need to be restored past the tombstone lifetime. Recovery is the same shape as Exchange work — parse the ESE database directly, read past the damage, extract what’s recoverable at the level of individual objects or attributes.

Windows Server Backup and VSS. Windows Server Backup produces .vhdx backup files on a target volume, with a backup catalog tracking what’s in them. The failure modes are the ones you’d expect: backup catalog corruption that makes the backup unmountable even though the .vhdx files are intact; .vhdx backup files themselves damaged by storage-substrate issues; shadow copy tables that reference blocks that no longer exist because the source volume has been reformatted. Recovery involves parsing the .vhdx files directly (the same parser we use for live Hyper-V VHDX) and reconstructing the backup catalog around them.

If your case is at this layer — a broken NTDS.dit, an unmountable Windows Server Backup archive, a VSS shadow copy that no longer resolves — call us. The recovery work fits the same pattern as the workloads with dedicated pages above.

The repair-tool trap repeats across every workload

One reason we keep this section on every Windows Server workload page is that the same failure mode keeps showing up under different names. Every Microsoft server workload ships with a repair tool that is documented as destructive when used against damaged storage, and every one of those tools gets reached for by admins in a hurry.

• DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS for SQL Server — deallocates whatever pages the checker can’t reconcile, potentially losing tables or ranges of rows.
• eseutil /p for Exchange and Active Directory — produces a mountable database by discarding whatever ESE couldn’t reconcile, often silently losing committed transactions.
• chkdsk /f /r for NTFS — safe on healthy volumes with minor damage, actively destructive on volumes with underlying storage-substrate problems.
• refsutil salvage for ReFS — scans a damaged ReFS volume and copies out what it can identify. Not destructive to the source when used carefully, but frequently produces incomplete results that admins then treat as authoritative.
• Reset-PhysicalDisk for Storage Spaces — Microsoft’s own documentation opens with “this is a destructive operation.” Wipes the pool metadata region on the specified drive.
• eseutil /d for Exchange and Active Directory — defragmentation utility that rewrites the entire database. Safe on healthy databases; catastrophic when run against a database with underlying damage, because there is no undo.
• Third-party “repair” tools for SQL, Exchange, and Storage Spaces — some of them work correctly on truly minor damage, most of them produce partial or subtly-wrong output on serious damage while presenting the output as complete.

The rule that covers all of these: if the storage layer under the workload is not fully healthy, none of these tools is safe to run on the live data. The safe workflow is to image the drives first, work against the images, and only run destructive repair tools against copies where the failure would be recoverable by reverting to the image. If you’ve already run one and the workload is now worse, that’s the point at which cases reach us. We can still recover from that state in most cases, because the original data is often still present in unaltered form on the drives. What we can’t do is undo a REPAIR write that landed on unallocated space that the drives have since overwritten.

What Gillware does at every layer

When a Windows Server case arrives — a physical server, a set of drives from a failed array, forensic images the customer made before things got worse, or drives from an S2D node that won’t rejoin — the work follows the same shape.

Image the hardware. Every drive that was ever part of the failed system goes through our imaging workflow. Physically damaged drives get whatever cleanroom work they need — head swaps, PCB work, platter burnishing, firmware repair — to produce the cleanest possible image. Drives that image fine on first attempt still get imaged rather than worked against directly. From this point forward, the original media is never modified.

Reconstruct the storage substrate. If the substrate is a hardware RAID array (Dell PERC, HPE Smart Array, LSI/Broadcom MegaRAID, Adaptec, or others), we reconstruct the array from the drive images using our internal RAID engine, which handles missing sectors, mismatched drives, and partially-corrupted parity in ways that no vendor controller can. If it’s a Storage Spaces pool, we parse the pool metadata regions from the drive images, reconstruct the slab allocation table, and reassemble the virtual disk from the correct slabs on the correct drives. If it’s a SAN LUN, we handle the LUN-specific reconstruction for the SAN platform involved (EqualLogic, PowerVault, MSA, 3PAR, and others).

Parse the filesystem. The reconstructed volume is handed to the appropriate filesystem parser. Our NTFS parser walks the MFT and extracts files. Our ReFS parser walks the B-tree metadata streams and does the same. Neither parser requires the volume to mount, which matters because most volumes we work with don’t.

Recover the workload files. Once the workload files are extracted — VHDX for Hyper-V, EDB for Exchange or Active Directory, MDF+LDF for SQL Server, or raw files and directories for a file server — the workload-specific parsers take over. VHDX gets walked block by block. EDB and NTDS.dit get parsed at the ESE page level. MDF gets parsed at the SQL Server storage engine level using our internal reimplementation. The output is whatever form the customer needs: a mountable VHDX for Hyper-V; a mountable EDB or a PST export for Exchange; an attachable MDF or table-level CSV exports for SQL Server; the actual folder structure for a file server.

Nothing in this workflow depends on the failed server booting, on the original storage controller being present, or on any Microsoft repair tool completing successfully. We reconstruct from the imaged media directly.

When to send a Windows Server case to us

The categories below are ones we’re engaged with weekly. Every case starts with a free consultation, and you approve all recovery fees in writing before any recovery work begins.

• Any Windows Server 2016, 2019, 2022, or 2025 case where a Microsoft workload — Hyper-V, Exchange, SQL Server, Active Directory, or a Windows Server Backup archive — won’t mount or won’t recover, and the underlying storage substrate has had a recent failure event.
• Any case where a Microsoft repair tool (DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS, eseutil /p, eseutil /d, chkdsk /f, refsutil salvage, Reset-PhysicalDisk) has completed and produced output that is worse than the pre-repair state.
• Any Windows Server on a Dell PowerEdge, PowerVault, or Compellent that has failed and needs both hardware-layer and workload-layer recovery. See our Dell server data recovery page for the hardware layer; this hub covers the workload layer above.
• Any Windows Server on an HPE ProLiant, MSA, 3PAR, or Nimble that has failed and needs the same. See our HP server data recovery page for the hardware layer.
• Any Storage Spaces or Storage Spaces Direct case where a virtual disk won’t attach, a pool won’t come out of read-only, or an S2D cluster refuses to reassemble after a node event. See Storage Spaces data recovery for the storage layer specifics.
• Any Windows Server case involving a RAW ReFS volume or an NTFS volume mounted as RAW. See ReFS data recovery or NTFS data recovery for the filesystem layer specifics.
• Any BitLocker-encrypted Windows Server volume where the recovery key is available and the underlying storage has failed. See BitLocker data recovery for the encryption layer specifics.
• Any Windows Server case where ransomware has damaged workload files (MDF, EDB, VHDX, NTDS.dit) but the underlying filesystem is intact. Recovery here focuses on scanning unallocated space for surviving copies and pre-encryption artifacts.
• Any case where the customer has already engaged another recovery service or Microsoft support and the case is now more complex than when it started.

Gillware has been recovering data from Windows Server workloads for more than two decades, from the software-RAID and dynamic-disk era through today’s Storage Spaces Direct and Azure Stack HCI deployments. Every major Microsoft server workload has been through our lab. We handle the whole stack — the physical drives at the bottom, the storage-virtualization layer above them, the filesystem above that, and the workload files at the top — as a single integrated recovery, because that’s how Windows Server failures actually happen.

This page is part of our broader Windows data recovery pillar. For adjacent hardware-vendor work, see our Dell server and HPE server hubs.