DataCore SANsymphony Data Recovery
DataCore SANsymphony is a storage virtualisation platform that pools disparate physical and array-presented storage into virtual disks served to hosts, with mirroring typically performed across two nodes for continuous availability. Recovery cases often involve the disk pool and mirrored virtual disk relationship, DataCore's own configuration database, or continuous data protection journal state rather than a single underlying disk.
Platform Lineage and Naming
DataCore's SANsymphony product line dates back to the early 2000s as one of the first commercial storage virtualisation platforms, rebranded SANsymphony-V for the generation that added a Hyper-V and VMware-integrated management console and broader hardware support. Later releases dropped the '-V' suffix, returning to the SANsymphony name while retaining the same underlying architecture.
DataCore extended the same storage engine into DataCore Hyperconverged Virtual SAN, combining SANsymphony's virtual disk and mirroring technology with compute on the same nodes for a hyper-converged deployment model, while the core disk pool, storage allocation unit and mirrored virtual disk concepts remain shared across all product names.
- SANsymphony-V — earlier product name for the current SANsymphony line
- DataCore Hyperconverged Virtual SAN — HCI packaging of the SANsymphony engine
- DataCore Server — the software component installed on each node
- CDP — Continuous Data Protection journal within SANsymphony
Generations and Models We Evaluate
| Generation / family | Models |
|---|---|
| Product names | SANsymphony-V, SANsymphony (current), DataCore Hyperconverged Virtual SAN |
| Deployment | Two-node mirrored pairs, multi-node scale-out pools, hyper-converged clusters |
| Disk types presented | Mirrored virtual disks, non-mirrored virtual disks, pass-through disks |
Architecture and Data Layout
SANsymphony aggregates physical disks or array-presented LUNs into disk pools, which are subdivided into storage allocation units (SAUs) — the basic unit of capacity allocation within a pool. Virtual disks are then carved from the pool and presented to hosts over Fibre Channel, iSCSI or as shared volumes to hyper-converged compute nodes.
For availability, virtual disks are commonly mirrored synchronously across two DataCore nodes, so each node holds a complete copy; this mirroring is distinct from the RAID protection (if any) provided by the underlying physical storage on each node. Pass-through disks bypass pooling and mirroring, exposing an underlying LUN largely as-is for cases where DataCore is used mainly for path management or CDP rather than pooling.
SANsymphony maintains its own configuration state — server, pool, and virtual disk relationships stored in the DataCore registry/log configuration — separately from the data itself; corruption or loss of this configuration can leave intact underlying disks unable to be reassembled into working virtual disks without reconstructing that metadata.
Protocols and formats: Fibre Channel, iSCSI, Shared/direct-attached (hyper-converged), NTFS/VMFS on presented virtual disks
- Mirrored virtual disks maintain synchronous copies across two nodes; a mirror split or resynchronisation in the wrong direction is a recurring cause of complex cases.
- CDP journals record a rolling history of writes to a virtual disk, allowing rollback to earlier points in time; journal exhaustion or corruption limits how far back a rollback can go.
- Storage allocation units are the granular blocks DataCore uses to allocate pool capacity to virtual disks, and pool-level metadata tracks which SAUs belong to which virtual disk.
Failure Scenarios
Logical failures
- DataCore configuration database (registry/log) corruption or loss
- Mirrored virtual disk split-brain or incorrect resynchronisation direction
- CDP journal corruption or exhaustion before a needed rollback point
- Accidental virtual disk deletion or pool reconfiguration
- Failed SANsymphony version upgrade affecting server-to-server communication
- Underlying array or LUN presentation changes breaking pass-through disk mapping
Hardware failures
- Failure of both mirror nodes, or one node plus a failed resynchronisation on the other
- Underlying physical disk or array failures within a disk pool exceeding its protection
- Storage fabric (FC/iSCSI) failures isolating nodes from pooled storage
- Server hardware failure hosting the DataCore Server software on hyper-converged nodes
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
Can data be recovered from one side of a mirrored virtual disk?
Often the surviving mirror node holds a usable copy, provided the mirror had not already gone out of sync before the failure; an evaluation of both nodes' state is needed to confirm.
What is the risk with pass-through disks?
Because pass-through disks largely bypass DataCore's own pooling, their recoverability depends mainly on the underlying array or LUN, though DataCore-level path or CDP configuration can still be relevant.
Does CDP let us always roll back to before the incident?
Only if the journal covers far enough back and has not been overwritten or corrupted; journal retention and health should be checked as part of any recovery evaluation.