Quantum StorNext & DXi Data Recovery
Quantum offers two architecturally distinct enterprise storage products that are often deployed alongside each other but must be recovered separately: StorNext, a shared file system for high-throughput collaborative workflows and tiered archiving, and DXi, a purpose-built deduplication appliance for backup. This page keeps the two clearly separated, since their metadata, protection schemes and typical failure modes do not overlap.
Platform Lineage and Naming
StorNext File System (SNFS) is Quantum's shared, high-performance file system, historically deployed on Metadata Controller (MDC) servers with dedicated metadata and journal LUNs, and storage pools built from stripe groups across attached disk arrays. Quantum later packaged the MDC role and storage together in the Xcellis platform, often paired with QXS disk arrays, and added StorNext Storage Manager for policy-based tiering out to LTO tape.
DXi is a separate product line of purpose-built backup deduplication appliances, spanning the DXi4000, DXi6000 and DXi9000 series, built around Quantum's blockpool deduplication repository. DXi appliances are typically ingest targets for backup software rather than general-purpose file systems, and their internal structures are unrelated to StorNext's.
- StorNext File System (SNFS)
- Quantum Xcellis
- Quantum QXS disk arrays
- StorNext Storage Manager (tape tiering)
- Quantum DXi4000, DXi6000, DXi9000
- blockpool (DXi deduplication repository)
Generations and Models We Evaluate
| Generation / family | Models |
|---|---|
| StorNext | Metadata Controllers (MDC), Xcellis, QXS series, standalone SNFS deployments |
| DXi | DXi4000, DXi6000, DXi9000 series |
Architecture and Data Layout
StorNext separates metadata from data: one or more Metadata Controllers maintain the file system's namespace on dedicated metadata and journal LUNs, while file data itself is striped across storage pools built from stripe groups spanning the attached disk arrays (commonly QXS). Clients with the StorNext client software access shared data directly over the SAN using this metadata/data split, which is what enables its high-throughput multi-client performance.
StorNext Storage Manager adds policy-driven tiering, migrating file data out to LTO tape while keeping a stub and metadata reference on disk, so a full StorNext recovery may need to reconcile disk-resident metadata against what has actually been migrated to tape.
DXi appliances are structured entirely differently: incoming backup data is deduplicated and stored in a blockpool repository, with the appliance presenting itself to backup software as a virtual tape library or disk target rather than a general file system. Recovery of a DXi appliance centres on the integrity of the blockpool and its internal reference tables, not on SNFS-style metadata and stripe groups.
Protocols and formats: Fibre Channel SAN (StorNext), NFS / SMB (StorNext client access), LTO tape (Storage Manager tiering), VTL / NFS / CIFS (DXi backup ingest)
- StorNext: metadata and journal LUNs are logically and often physically separate from data stripe groups, and both must be preserved together for a coherent recovery.
- DXi: the blockpool is a self-contained deduplication repository with its own reference and container structures, unrelated to StorNext's stripe-group layout.
Failure Scenarios
Logical failures
- StorNext: metadata or journal LUN corruption
- StorNext: damaged stripe group or storage pool configuration
- StorNext: Storage Manager policy errors leaving files only partially migrated or truncated on disk
- StorNext: accidental deletion of files or directories from the shared namespace
- DXi: blockpool reference table corruption
- DXi: failed deduplication appliance firmware upgrade
- DXi: backup catalogue and appliance state falling out of sync
Hardware failures
- StorNext: Metadata Controller failure or MDC failover issues
- StorNext: multiple drive failures within a QXS array exceeding RAID tolerance
- DXi: multiple drive failures within the appliance's internal RAID exceeding tolerance
- DXi: controller failure on the appliance itself
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
If our StorNext file system is damaged, is the DXi backup appliance affected too?
Not directly. They are architecturally separate products with independent storage structures, so a StorNext fault does not itself imply damage to a DXi appliance, though both are worth checking if backups were also running through the same infrastructure.
Can StorNext data be recovered if some files were tiered to tape?
It depends on whether the on-disk stub and metadata are intact and whether the tape media itself is accessible; the evaluation needs to establish the state of both the disk pool and the associated tape library.
Is DXi recovery the same as generic backup deduplication recovery?
DXi uses Quantum's own blockpool structures, so while the general challenge of reconstructing a deduplication repository is similar across vendors, the specific internal format is unique to DXi.