StarWind Virtual SAN Data Recovery
StarWind Virtual SAN is a software-defined storage product that mirrors storage synchronously between two or three nodes, commonly deployed as a virtual storage appliance (VSA) alongside VMware vSphere or Microsoft Hyper-V. Recovery cases typically revolve around replication state between nodes, heartbeat-driven failover decisions, and the health of the underlying .img or .swdsk device files rather than a single physical disk.
Platform Lineage and Naming
StarWind Software has offered its Virtual SAN product for well over a decade, evolving from an iSCSI target product into a full hyper-converged storage layer aimed at small and mid-sized deployments that need shared storage without a physical SAN. It is commonly deployed as a Virtual Storage Appliance (VSA) running inside the same hypervisor cluster it serves, though it also supports installation directly on Windows Server hosts (HCA — hyperconverged appliance model).
The product supports both VMware vSphere and Microsoft Hyper-V environments, presenting replicated storage over iSCSI to hosts in either case, with two-node configurations (the most common deployment) and three-node configurations for additional redundancy.
- VSA — StarWind's Virtual Storage Appliance deployment model
- HCA — hyperconverged appliance, StarWind installed directly on Windows Server hosts
- LSFS — Log-Structured File System, StarWind's optimised device format
- .img / .swdsk — StarWind's virtual disk image file formats
Generations and Models We Evaluate
| Generation / family | Models |
|---|---|
| Deployment models | VSA (virtual appliance), HCA (bare Windows Server install) |
| Hypervisor targets | VMware vSphere/ESXi, Microsoft Hyper-V |
| Cluster sizes | 2-node synchronous replication (most common), 3-node replication |
| Device formats | LSFS (log-structured), flat/thick .img and .swdsk devices |
Architecture and Data Layout
StarWind presents storage as virtual disk devices — either flat/thick provisioned .img/.swdsk files or LSFS-formatted devices — which are synchronously replicated between two or three nodes at the block level, then exposed to hosts as iSCSI targets consumed as VMFS or CSV/NTFS datastores.
LSFS is StarWind's own log-structured format designed to improve performance for snapshot-heavy and thin-provisioned workloads by writing sequentially and later reclaiming space, in contrast to a flat device file which is a direct, fixed-layout image of the presented disk.
Node health and split-brain avoidance are managed through a heartbeat mechanism between replica nodes; when heartbeat communication is lost, StarWind uses node-majority (in 3-node configurations) or configured witness/priority rules (in 2-node configurations) to decide which node continues serving I/O, with the other side requiring a full resynchronisation once reconnected.
Protocols and formats: iSCSI, VMFS (vSphere datastores), CSVFS/NTFS (Hyper-V), SMB3 (some deployment scenarios)
- LSFS devices store data log-structured with periodic reclaim, which changes how partial corruption manifests compared with a flat device file that maps directly to presented blocks.
- Synchronous replication means both replica partners should hold identical data under normal operation; divergence typically only occurs after a split-brain event or an interrupted resynchronisation.
Failure Scenarios
Logical failures
- Split-brain between replica nodes after a heartbeat and interconnect failure occurring simultaneously
- Full resynchronisation triggered in the wrong direction, overwriting the more current replica
- LSFS metadata corruption during an interrupted reclaim cycle
- Accidental deletion of .img/.swdsk device files or their containing datastore
- Failed StarWind service upgrade leaving replica partners unable to reconnect
- VMFS or NTFS corruption within an otherwise healthy replicated device
Hardware failures
- Failure of both replica nodes, or one node plus a failed resync on the survivor
- Underlying physical disk failures on a node hosting .img/.swdsk device files
- Network interconnect failure between nodes coinciding with a node outage
- Storage controller or RAID failure beneath a StarWind device on a single node
What Not To Do Before an Evaluation
- Do not run rebuilds, reconstructions or re-initialisations against an array that has already lost more drives than its protection level allows.
- Do not recreate pools, aggregates, disk groups, storage pools or clusters — these operations write new metadata over the structures a recovery needs.
- Do not swap drives between slots, and do not reorder shelves. Record the original slot and shelf positions before removing anything.
- Do not run file-system repair tools against production volumes before the underlying storage layer has been evaluated.
- Do not restore a backup or replication set over the affected volumes until the recovery scope has been assessed.
- Do not eradicate deleted volumes or empty recycle/destroyed states on platforms that hold deleted data for a retention window.
Our Evaluation and Recovery Process
- Intake and platform identification — array model, generation, firmware, protection layout and the sequence of events that led to the failure.
- Read-only evaluation of the media and array structures, including assessment of drive health and the extent of any physical damage.
- Forensic imaging of all contributing media, with cleanroom work where drives require it. Originals are preserved unaltered.
- Reconstruction of the storage layer — pools, aggregates, parity groups, chunklets, extent groups or objects — from the images.
- Extraction of the layers above: file systems, virtual machines, databases, mailboxes and shares.
- Verification against a file list and customer-nominated critical data, followed by secure return on encrypted media.
Frequently Asked Questions
One of our two nodes failed — is the surviving node enough?
Often yes, provided the surviving node was fully in sync at the time of failure; if a split-brain or partial resync had occurred beforehand, an evaluation of both nodes is needed to confirm which holds the more complete data.
What causes a split-brain in a 2-node StarWind configuration?
It typically happens when the heartbeat and synchronisation interconnects both fail at the same time, causing each node to believe it should continue serving I/O independently, leading to divergent data on each side.
Does LSFS complicate recovery compared with flat devices?
LSFS's log-structured layout and background reclaim process add a layer of internal metadata beyond a flat device file, which needs to be accounted for during reconstruction, but it does not make recovery evaluation impossible.