Dot Hill AssuredSAN Data Recovery
Dot Hill's AssuredSAN family is best known not just under its own brand but as the OEM engineering behind several rebadged products, most notably early to mid-generation HPE MSA arrays and Dell PowerVault MD3 systems. Dot Hill was acquired by Seagate in 2015; recovery work on any of these rebadges depends on identifying whether the array uses Dot Hill's virtual or linear storage pool model, since the two have materially different metadata layouts.
Platform Lineage and Naming
Dot Hill developed the AssuredSAN 2000, 3000, 4000, Ultra48 and Pro 5000 series of dual-controller SAN arrays, licensing the same core engineering to other vendors who rebadged it under their own names — most visibly HPE's MSA line in its earlier generations and Dell's PowerVault MD3 series, along with other OEM relationships over the product's life.
Seagate acquired Dot Hill in 2015, continuing the AssuredSAN engineering within Seagate's enterprise systems business; the practical effect for recovery purposes is that many arrays sold under different brand names share very similar, and in some generations identical, internal architecture.
- Dot Hill AssuredSAN 2000, 3000, 4000 series
- AssuredSAN Ultra48, Pro 5000
- HPE MSA (early to mid generations, OEM lineage)
- Dell PowerVault MD3 series (OEM lineage)
- Seagate (post-2015 owner)
Generations and Models We Evaluate
| Generation / family | Models |
|---|---|
| AssuredSAN | 2000, 3000, 4000, Ultra48, Pro 5000 series |
| OEM rebadges | HPE MSA (select generations), Dell PowerVault MD3 series |
Architecture and Data Layout
AssuredSAN controllers support two distinct pool models: linear storage pools, which map closely to traditional fixed RAID groups and volumes, and virtual storage pools, which add thin provisioning and tiering on top of an internal page-based allocation scheme. Identifying which pool type is in use is one of the first steps in any recovery, since their metadata structures differ substantially.
Dual-controller configurations mirror cache and coordinate ownership of volumes between controllers (RAIDcore-managed metadata), so controller failover history and firmware version are relevant context when a fault involves the controller layer rather than the drives themselves.
Because the same core engineering underlies several OEM brands, an array's outward badge (Dot Hill, HPE MSA or Dell PowerVault MD3) does not always predict its internal pool type — that has to be established from the array's own metadata.
Protocols and formats: Fibre Channel, iSCSI, SAS (host-attached configurations)
- Linear pools use conventional fixed RAID groups (RAID 5, 6, 1/10) mapped directly to volumes.
- Virtual pools use page-based thin provisioning with optional automated tiering, requiring a different metadata approach during reconstruction than linear pools.
Failure Scenarios
Logical failures
- Deleted volumes or pools, linear or virtual
- Failed conversion between linear and virtual pool types
- Controller metadata corruption affecting volume ownership
- Firmware upgrade failures
- Host file system corruption inside presented volumes
Hardware failures
- Multiple drive failures exceeding RAID tolerance within a pool
- Controller failure with incomplete cache mirroring to its partner
- Backplane or midplane faults
- Power-loss events during tiering or rebuild operations on virtual pools
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
Our array is badged as an HPE MSA — is this still a Dot Hill recovery?
Several HPE MSA generations were built on Dot Hill's AssuredSAN engineering, so the internal architecture, and the recovery approach, is assessed the same way regardless of the external badge; the exact generation still needs to be confirmed.
Does it matter whether our pool is linear or virtual?
Yes. Linear and virtual pools use materially different metadata structures, so establishing which type is in use is one of the first steps before any reconstruction work begins.
Does Seagate's ownership affect recovery of an older Dot Hill unit?
Ownership affects ongoing support and firmware availability rather than the recoverability of the underlying RAID structures, which an independent evaluation can assess directly.