HP EVA and P6000 EVA Data Recovery
The HP EVA (Enterprise Virtual Array) and its successor branding as the HP/HPE P6000 EVA were mid-range Fibre Channel SAN arrays widely deployed through the 2000s and early 2010s. These are legacy platforms, long past end of support, and recovery work on them is usually driven by the age of the hardware and the difficulty of sourcing working controllers rather than by any recent design flaw.
Platform Lineage and Naming
HP launched the EVA line with the EVA3000 and EVA5000, followed by the EVA4000, EVA6000 and EVA8000, and later the EVA4100, EVA6100 and EVA8100. The EVA4400 consolidated the controllers and shelf into a single enclosure aimed at smaller deployments. HP subsequently rebranded the line as the P6000 EVA family, comprising the P6300, P6350, P6500 and P6550, which continued the same virtual-disk architecture on updated hardware.
All generations were managed through Command View EVA, HP's management application that held configuration metadata about disk groups and virtual disks separately from the array's own internal structures — a detail that matters when the management server and the array have become separated over the system's long service life.
HP's separate StoreVirtual (formerly LeftHand, also sold as the P4000 series) was a different, iSCSI-based clustered storage line from the same era and is not part of the EVA/P6000 lineage; it is covered on its own page rather than here.
- HP EVA — Enterprise Virtual Array, the original product name
- HP/HPE P6000 EVA — the rebranded continuation of the EVA line (P6300/P6350/P6500/P6550)
- VCS / XCS — Virtual Controller Software / the later-named controller operating environment
- Vraid0, Vraid1, Vraid5, Vraid6 — the array's virtual RAID levels applied to virtual disks
- Command View EVA — the management application holding array configuration
- StoreVirtual / LeftHand / P4000 — a related but architecturally separate HP iSCSI storage line, not covered on this page
Generations and Models We Evaluate
| Generation / family | Models |
|---|---|
| Early EVA | EVA3000, EVA5000 — dual-controller Fibre Channel arrays with separate disk enclosures |
| Mid-generation EVA | EVA4000, EVA6000, EVA8000, EVA4100, EVA6100, EVA8100 |
| Consolidated EVA | EVA4400 — controllers and initial shelf in one enclosure |
| P6000 EVA (rebrand) | P6300, P6350, P6500, P6550 — continuation of the EVA architecture under new branding |
Architecture and Data Layout
EVA and P6000 EVA arrays use a virtualised storage model: physical disks are grouped into disk groups, and virtual disks are then carved out of a disk group's aggregate capacity rather than mapping directly to fixed physical spindles. This gives flexible provisioning but means that reconstructing a virtual disk requires understanding the disk group's layout across all its member drives.
Redundant storage sets distribute virtual disk data and parity across the disk group's members, with the array's chosen Vraid level determining the protection scheme — Vraid1 mirrors, Vraid5 uses distributed parity, and later arrays added Vraid6 for dual-parity protection. Metadata describing disk group membership and virtual disk placement is stored on the array itself, alongside quorum-style structures the controllers use to agree on configuration state.
VCS, later renamed XCS, is the controller software running this virtualisation layer; Command View EVA is a separate management application that reads and writes configuration through the controllers rather than owning the array's on-disk structures directly.
Protocols and formats: Fibre Channel, VMFS, NTFS, Command View EVA management
- Disk groups pool physical drives, and virtual disks are allocated from that pool with the array-assigned Vraid level (Vraid0, Vraid1, Vraid5 or the later Vraid6) rather than a fixed physical RAID set.
- Redundant storage sets spread data and parity/mirror copies across the disk group's drives, so a case involving several failed drives needs the disk group's full membership, not just the drives obviously reporting faults.
- Configuration and quorum metadata on the controllers and drives must be consistent for the array to correctly present its virtual disks; this metadata is separate from whatever Command View EVA has cached on its management server.
Failure Scenarios
Logical failures
- Virtual disk or disk group deleted or reconfigured in error
- Corrupted controller metadata following a firmware update or controller replacement
- Command View EVA database out of sync with the array's actual configuration
- Vraid level changed or a virtual disk migrated between disk groups mid-operation
- File system or VMFS corruption on volumes presented by an otherwise healthy array
Hardware failures
- Multiple drive failures within a disk group exceeding the configured Vraid protection
- Dual controller failure, common on hardware this age given parts scarcity
- Backplane, loop or Fibre Channel switch failures affecting shelf connectivity
- Battery or cache module failure leading to unflushed writes
- Aging or failing drives across an entire shelf due to the platform's age
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 the P6000 EVA a different architecture from the original EVA?
No. The P6000 EVA (P6300/P6350/P6500/P6550) is a rebranding and hardware refresh of the same disk-group and virtual-disk architecture used throughout the EVA line, running VCS or its later XCS naming.
Can Command View EVA alone tell you what happened to the array?
Not reliably on its own. Command View EVA's database can drift from the array's actual on-disk configuration, especially after hardware changes, so the array's own controller and drive metadata needs to be examined directly.
Is StoreVirtual/LeftHand covered by EVA recovery methods?
No. StoreVirtual (formerly LeftHand, also sold as the P4000 series) is an unrelated iSCSI clustered architecture; see the dedicated HP LeftHand page rather than this one.
Is it still worth attempting recovery on such old hardware?
It depends on the condition of the drives and controllers, which is why an evaluation of the specific unit is needed — these platforms are long out of support, and parts availability affects what approaches are practical.