Sun StorEdge and StorageTek Data Recovery
Sun StorEdge and StorageTek cover a long and varied line of disk arrays sold by Sun Microsystems and its StorageTek acquisition, spanning purpose-built Sun controllers, rebadged Engenio/LSI platforms and Hitachi-derived high-end systems. Recovery work on this family starts by identifying which underlying controller technology a given model actually uses, since the internal architecture differs sharply across the range.
Platform Lineage and Naming
Sun's StorEdge line began with early modular arrays such as the A1000 and A3500, moved through the T3 and 3510/3511 SCSI and Fibre Channel arrays, and into the midrange 6120, 6130, 6140, 6180, 6540 and 6580/6780 families, many of which were rebadged Engenio (later LSI) controller platforms sold under the Sun name.
Sun's acquisition of StorageTek brought the StorageTek D-series and FlexLine arrays into the same portfolio, again largely built on OEM controller technology rather than Sun-original designs.
At the high end, the StorEdge 9970, 9980, 9985 and 9990 arrays were Hitachi-derived platforms — rebadged versions of Hitachi enterprise storage — sharing much of their internal architecture, RAID microcode and diagnostic approach with contemporary Hitachi systems rather than with Sun's own midrange line.
- Sun StorEdge A1000, A3500, T3
- Sun StorEdge 3510, 3511
- Sun StorEdge 6120, 6130, 6140, 6180, 6540, 6580, 6780
- StorageTek D-series, FlexLine series
- StorEdge 9970, 9980, 9985, 9990 — Hitachi-derived enterprise arrays
- Rebadged Engenio / LSI controller platforms (6000 series)
Generations and Models We Evaluate
| Generation / family | Models |
|---|---|
| Early modular | StorEdge A1000, A3500 |
| Fibre/SCSI midrange | StorEdge T3, 3510, 3511 |
| Engenio/LSI-derived | StorEdge 6120, 6130, 6140, 6180, 6540, 6580, 6780 |
| StorageTek acquired lines | StorageTek D-series, FlexLine series |
| Hitachi-derived enterprise | StorEdge 9970, 9980, 9985, 9990 |
Architecture and Data Layout
Most midrange StorEdge arrays present block LUNs over Fibre Channel or SCSI to Solaris (and other) hosts, with volume management handled above the array by Sun Volume Manager, its successor Solaris Volume Manager, or third-party tools such as Veritas VxVM — meaning a full picture of the logical layout often requires understanding both the array's own RAID configuration and the host-side volume manager metadata layered on top of it.
File systems built on these LUNs are typically UFS, later ZFS, or Sun's QFS shared file system in clustered and archival configurations, so the recovery target above the block layer depends on which of these was in use.
The 99xx-series arrays differ fundamentally from the rest of the family: they are Hitachi enterprise storage rebadged for Sun/Oracle sale, and their internal RAID group, LDEV and controller microcode concepts follow Hitachi's architecture rather than Sun's other StorEdge designs.
Protocols and formats: Fibre Channel, SCSI, UFS, QFS, ZFS, Solaris Volume Manager / Sun Volume Manager, Veritas VxVM
- RAID configuration on the Engenio/LSI-derived 6000-series arrays follows that controller family's own group and volume constructs rather than a Sun-original scheme.
- Where Solaris Volume Manager, Sun Volume Manager or VxVM stripes, mirrors or concatenates array LUNs into larger host-level volumes, that host-side metadata must be reconstructed alongside the array's own RAID layout.
- The 99xx Hitachi-derived arrays use Hitachi's LDEV and RAID group constructs; treating them as if they share architecture with the Sun-original midrange line leads to incorrect assumptions about parity layout and cache handling.
Failure Scenarios
Logical failures
- Deleted or reconfigured LUNs at the array or volume-manager level
- Sun/Solaris Volume Manager or VxVM metadata corruption above healthy array LUNs
- Failed firmware update or controller replacement leaving inconsistent configuration
- UFS, QFS or early ZFS file system corruption on presented LUNs
- Accidental array reinitialisation during decommissioning or redeployment
Hardware failures
- Multiple drive failures within a RAID group beyond parity tolerance
- Failed or mismatched controller replacement on legacy, discontinued hardware
- Cache battery or NVRAM failure with unflushed writes on older arrays
- Backplane, loop or expander failures on ageing SCSI/Fibre Channel enclosures
- Parts scarcity affecting replacement of failed components on end-of-life models
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
Are the StorEdge 9970/9980/9985/9990 the same as other StorEdge arrays?
No. Those models are rebadged Hitachi enterprise arrays and follow Hitachi's RAID and LDEV architecture, quite different from the Engenio/LSI-derived 6000 series or Sun's original A/T-series designs.
Do we need the original volume manager configuration to recover data?
If Sun Volume Manager, Solaris Volume Manager or Veritas VxVM was layering volumes across array LUNs, that configuration is important context — the array's own RAID recovery only restores the LUNs, not the host-level volume structure built on top of them.
These arrays are long out of production — does that limit what can be done?
It can limit sourcing of exact replacement parts, which is why an evaluation typically starts with imaging accessible drives rather than relying on hardware repair of the original controller.