Hitachi Universal Storage Platform Data Recovery
The Hitachi Universal Storage Platform (USP) generation, together with its Lightning 9900/9900V predecessors and USP V/VM successors, established the enterprise virtualisation and parity-group architecture that Hitachi's later Virtual Storage Platform (VSP) line continued to build on. These arrays were also sold under OEM agreements as the HP StorageWorks XP series and Sun StorageTek 9990, so the same underlying platform can appear under several vendor badges.
Platform Lineage and Naming
Hitachi's enterprise array line ran from the Lightning 9900 and 9900V through the TagmaStore Universal Storage Platform (USP) and Network Storage Controller (NSC), then to USP V and the smaller USP VM. USP V introduced Universal Volume Manager, which let the array virtualise external third-party storage arrays behind its own front end, and Hitachi Dynamic Provisioning was introduced during this generation as an early thin-provisioning capability.
This platform family was OEM'd extensively: Hewlett-Packard sold equivalent hardware as the HP StorageWorks XP12000 and XP24000, and Sun Microsystems sold it as the Sun StorageTek 9990. Hitachi's own line subsequently continued into the Virtual Storage Platform (VSP), which carries forward the same parity-group and external-virtualisation concepts — see the dedicated VSP page for that generation, and the HPE XP page for the HP-badged equivalents.
- Hitachi Lightning 9900, 9900V
- TagmaStore Universal Storage Platform (USP), Network Storage Controller (NSC)
- USP V, USP VM
- Rebadged as HP StorageWorks XP12000 / XP24000 — see the HPE XP page
- Rebadged as Sun StorageTek 9990
- Successor: Hitachi Virtual Storage Platform (VSP) — see the dedicated VSP page
Generations and Models We Evaluate
| Generation / family | Models |
|---|---|
| Lightning generation | 9900, 9900V |
| TagmaStore generation | USP, USP VM, NSC55 |
| USP V generation | USP V, USP VM |
| OEM equivalents | HP StorageWorks XP12000/XP24000, Sun StorageTek 9990 |
Architecture and Data Layout
These arrays organise physical disks into parity groups, Hitachi's term for a RAID-protected disk group, from which Logical Devices (LDEVs) are carved as the fundamental addressable unit. Where a single LDEV needs to exceed the size available from one parity group's slice, Hitachi's LUSE (LU Size Expansion) feature concatenates multiple LDEVs into a larger logical unit.
A large shared cache and shared memory subsystem sits between host-facing front-end directors and the back-end parity groups, coordinating cache coherency, replication (TrueCopy/Universal Replicator) and, from USP V onward, dynamic provisioning pool management.
Universal Volume Manager, introduced with USP V, allows the array to present externally attached third-party storage as if it were internal capacity — meaning some LDEVs visible to a host may physically reside on a separate array altogether, a detail that materially affects where a recovery evaluation needs to look for the underlying data.
Protocols and formats: Fibre Channel, FICON, ESCON (Lightning 9900 generation), iSCSI (later models), TrueCopy, Universal Replicator, Hitachi Dynamic Provisioning
- Parity groups are Hitachi's RAID-protected disk groupings (commonly RAID 1, RAID 5 or RAID 6 depending on generation and configuration), with LDEVs carved from a parity group's capacity.
- LUSE-concatenated LDEVs span multiple underlying LDEVs and parity-group slices, so reconstructing one logical unit may require correlating several physical parity groups.
- Where Universal Volume Manager virtualises external storage, the array's own parity groups may hold none of a given LDEV's actual data — the physical media resides on the externally attached array instead.
Failure Scenarios
Logical failures
- Deleted or reformatted LDEVs or dynamic provisioning pool volumes
- LUSE concatenation metadata corruption affecting a spanned logical unit
- Failed microcode update affecting shared memory or cache configuration
- Mismanaged TrueCopy/Universal Replicator relationship overwriting a volume
- External virtualisation mapping lost or misconfigured under Universal Volume Manager
Hardware failures
- Multiple disk failures within a parity group beyond its RAID tolerance
- Shared memory or cache module failure affecting in-flight or cached writes
- Front-end director or back-end disk adapter failures
- Externally virtualised array failure affecting LDEVs mapped through Universal Volume Manager
- Power or environmental events affecting a full frame
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 a USP the same platform as an HP XP or Sun 9990?
Yes, at the hardware and firmware level these were OEM'd versions of the same Hitachi platform. See the HPE XP page for details specific to that badging.
How does external virtualisation change the recovery approach?
If Universal Volume Manager maps an LDEV to externally attached storage, the physical data lives on that external array rather than the USP's own parity groups, so the evaluation needs to identify and include the external array.
Is this the same as recovering a VSP?
USP/USP V share architectural concepts with the later Virtual Storage Platform, but they are earlier-generation hardware and firmware. See the dedicated VSP page for that platform.