Pillar Axiom Data Recovery
Pillar Axiom, later sold as Oracle Axiom following Oracle's acquisition of Pillar Data Systems, is a modular SAN platform built around quality-of-service-driven data placement. Recovery work depends heavily on understanding how Axiom deliberately spreads LUN data across brick regions according to configured priority, rather than laying it out in a simple contiguous pattern.
Platform Lineage and Naming
Pillar Data Systems developed the Axiom storage system as a modular SAN with distinct control and capacity components, releasing the Axiom 300, 500 and 600 generations with increasing performance and capacity. Oracle acquired Pillar Data Systems and continued the product line under the Oracle Axiom name before eventually transitioning customers toward the Oracle FS-branded flash storage system as its successor.
Axiom's defining characteristic throughout its generations was quality-of-service-driven placement — administrators could assign priority to LUNs, and the system would place that data on the most appropriate physical regions of the Brick storage enclosures accordingly.
- Pillar Axiom 300, 500, 600
- Oracle Axiom — the branding used after Oracle's acquisition of Pillar Data Systems
- Pilot — the management controller pair
- Slammer — the storage control unit(s) fronting the Bricks
- Brick — the disk storage enclosure
- Oracle FS System — the successor platform to Axiom
Generations and Models We Evaluate
| Generation / family | Models |
|---|---|
| Axiom generations | Axiom 300, Axiom 500, Axiom 600 |
| Control components | Pilot management controller, Slammer control units (Fibre Channel and iSCSI variants) |
| Capacity components | Serial ATA and Fibre Channel Bricks in varying capacities |
Architecture and Data Layout
An Axiom system separates management from data movement: the Pilot controller pair handles system management and configuration, while one or more Slammer control units handle the actual host-facing I/O and connect to the Brick storage enclosures that hold the physical drives.
Bricks are internally divided into regions based on physical characteristics such as track position, and Axiom's QoS engine places LUN data into faster or slower regions according to the Storage Profile and Storage Domain assigned to that LUN — so two LUNs on the same Brick set can have meaningfully different physical layouts based purely on configured priority.
Storage Domains group Bricks for isolation and management purposes, and Storage Profiles define the performance and redundancy characteristics (striping, mirroring, RAID level) applied to a given LUN within its domain.
Protocols and formats: Fibre Channel, iSCSI, NFS (via NAS Slammer variants), Pillar AxiomONE / Oracle Axiom management software
- LUN data is not laid out uniformly across a Brick; QoS-driven placement moves higher-priority LUN data toward higher-performance regions and lower-priority data toward other regions of the same physical drives.
- Reconstructing an Axiom LUN correctly requires the Storage Profile and Storage Domain configuration in addition to the raw Brick contents, since the RAID level and placement logic applied depend on that configuration.
- Slammer failover configurations and multi-Brick striping mean that a complete set of Bricks belonging to the affected Storage Domain is normally needed, not just the Brick that appears to hold a given LUN's primary data.
Failure Scenarios
Logical failures
- Deleted LUNs, Storage Domains or Storage Profiles
- Failed Pilot configuration restore after a management controller replacement
- Corrupted QoS placement metadata following an unclean shutdown
- Accidental reconfiguration of Storage Profiles affecting existing LUNs
- File system corruption above healthy LUNs on Fibre Channel or iSCSI hosts
Hardware failures
- Multiple drive failures within a Brick beyond the configured RAID tolerance
- Failed Slammer control unit affecting host access to associated Bricks
- Pilot controller failure alongside loss of configuration backups
- Brick backplane or interconnect failures
- Parts scarcity for this discontinued, end-of-life platform
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
Why does Axiom recovery need the Storage Profile configuration, not just the Bricks?
Because Axiom's QoS engine places LUN data into different physical regions of the Bricks depending on the Storage Profile and Domain assigned, the profile configuration explains how a given LUN's data is actually laid out across those regions.
Can a single Brick be recovered on its own?
It depends on whether the affected LUNs were striped or mirrored across multiple Bricks in the same Storage Domain. Many configurations require the full set of Bricks in that domain.
Is Axiom still supported by Oracle?
Axiom has been succeeded by the Oracle FS System, and Axiom hardware is long past end of life, which is a factor in how a recovery evaluation approaches parts and controller access.