Hitachi Unified Storage & Adaptable Modular Storage Data Recovery
Hitachi's modular storage line runs from the original Thunder 9500V and Workgroup Modular Storage through Adaptable Modular Storage (AMS) and into Hitachi Unified Storage (HUS), including the enterprise-class HUS VM. These arrays share a common controller-and-RAID-group design tradition even as capacity, connectivity and dynamic provisioning features evolved across generations, and a recovery evaluation needs to identify exactly which generation's pool and RAID structures are in play.
Platform Lineage and Naming
Hitachi's modular array line began with the Thunder 9500V and the Workgroup Modular Storage (WMS) series, aimed at mid-range block workloads. These were succeeded by Adaptable Modular Storage (AMS), spanning the AMS 200, 500 and 1000 generation and later the AMS 2100, 2300 and 2500 generation with dual-controller designs and broader host connectivity.
Hitachi rebranded and extended the line as Hitachi Unified Storage (HUS), with the HUS 110, 130 and 150 models continuing the modular block architecture, and HUS VM applying enterprise-class virtualisation and Hitachi Dynamic Provisioning concepts in a more compact chassis than the full Virtual Storage Platform line. HUS also had a unified variant with a NAS (file module) head derived from Hitachi's BlueArc acquisition, sitting in front of the block back end.
- Adaptable Modular Storage (AMS 200, 500, 1000, 2100, 2300, 2500)
- Workgroup Modular Storage (WMS)
- Thunder 9500V — predecessor modular array
- Hitachi Unified Storage (HUS 110, 130, 150, HUS VM)
- HUS file module — BlueArc-derived NAS head for unified configurations
Generations and Models We Evaluate
| Generation / family | Models |
|---|---|
| Early modular | Thunder 9500V, Workgroup Modular Storage (WMS) |
| AMS generation 1 | AMS 200, AMS 500, AMS 1000 |
| AMS generation 2 | AMS 2100, AMS 2300, AMS 2500 |
| HUS generation | HUS 110, HUS 130, HUS 150, HUS VM |
| Unified/file | HUS file module (BlueArc-derived NAS head) — see the Hitachi HNAS page for file-side architecture |
Architecture and Data Layout
Across the AMS and HUS generations, dual redundant controllers manage back-end disk arranged into RAID groups, with Hitachi Storage Navigator Modular (and later Hitachi Device Manager) used for provisioning, RAID configuration and monitoring.
Later AMS and HUS generations added Dynamic Provisioning pools, which aggregate multiple RAID groups into a pool from which thin-provisioned virtual volumes are carved — meaning a given volume's blocks can be spread across several underlying RAID groups rather than one fixed set of disks.
In unified HUS configurations, a BlueArc-derived file module sits in front of the block controllers to present NFS and SMB shares, translating file-level requests into block I/O against the same back-end RAID groups or pools; the file module's own file-system internals follow the same lineage as Hitachi's NAS platform, which is covered on the dedicated HNAS page.
Protocols and formats: Fibre Channel, iSCSI, NFS, SMB/CIFS (unified/file module configurations), Hitachi Dynamic Provisioning
- RAID groups on these platforms are typically RAID 1+0, 5 or 6, configured per array generation and workload.
- Where Dynamic Provisioning pools are in use, a single virtual volume's data is striped across all RAID groups in the pool, so reconstructing that volume requires resolving the pool's page-mapping metadata rather than a single RAID group's layout.
- Unified configurations layer a file system on top of block LUNs presented from the pool or RAID groups, adding a further translation layer that must be accounted for during recovery.
Failure Scenarios
Logical failures
- Deleted or reformatted volumes, pools or file shares
- Dynamic Provisioning pool metadata corruption
- Failed microcode/firmware upgrade affecting RAID group or pool configuration
- Accidental LUN or pool deletion during reconfiguration
- File system corruption on the HUS file module in unified configurations
Hardware failures
- Multiple disk failures within a RAID group beyond its parity tolerance
- Controller failure, including failed failover between dual controllers
- Cache/battery backup failure affecting unflushed writes
- Back-end SAS/FC loop or expansion tray faults
- File module hardware failure in unified configurations
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
Is AMS the same architecture as HUS?
They share the same modular design lineage — dual controllers over RAID groups — but HUS generations added Dynamic Provisioning pools more broadly and, in unified configurations, a BlueArc-derived file module. Each generation is evaluated on its own configuration.
How does Dynamic Provisioning affect recovery?
A thin-provisioned pool volume's data can be spread across several RAID groups, so recovery needs to resolve the pool's mapping metadata rather than assume the volume sits on one fixed RAID group.
We have a unified HUS with file shares — is that covered here?
The block and RAID/pool layer is covered on this page; the file module's file-system internals follow the same architecture as Hitachi's NAS platform, detailed on the dedicated HNAS page.