Qumulo Core Data Recovery
Qumulo Core is a scale-out file storage platform deployed on Qumulo-branded, HPE and Supermicro node hardware, as well as in the public cloud through Cloud Native Qumulo. Because Qumulo distributes both data and its own real-time analytics metadata across a cluster's nodes, recovery cases centre on cluster-wide quorum and the Scalable Block Store layer rather than any individual drive.
Platform Lineage and Naming
Qumulo was founded by engineers with backgrounds from Isilon's original scale-out file system team, and built Qumulo Core (originally referred to by the product family name QF2) as a new scale-out file system emphasising real-time capacity and file analytics alongside standard NAS protocols. It shipped initially on Qumulo's own qualified hardware nodes.
Qumulo subsequently expanded hardware support to HPE Apollo and Supermicro platforms sold through partner channels, and introduced Cloud Native Qumulo (CNQ) to run the same Qumulo Core software directly on cloud infrastructure such as AWS, decoupling the software from any single hardware vendor.
- QF2 — Qumulo's original internal/product name for its scale-out file system
- Qumulo Core — the current product name
- Cloud Native Qumulo (CNQ) — cloud-hosted deployment of Qumulo Core
- Scalable Block Store (SBS) — Qumulo's underlying distributed storage engine
Generations and Models We Evaluate
| Generation / family | Models |
|---|---|
| On-premises hardware | Qumulo-branded nodes, HPE Apollo-based nodes, Supermicro-based nodes |
| Cloud | Cloud Native Qumulo on AWS and other supported cloud platforms |
| Cluster sizes | Small edge clusters through large multi-petabyte scale-out clusters |
Architecture and Data Layout
Qumulo Core is built on the Scalable Block Store (SBS), a distributed layer that spreads both file data and file system metadata across every node in the cluster, protected by data protection schemes analogous to erasure coding that tolerate node and drive failures without designating dedicated parity nodes.
A distinguishing feature is Qumulo's real-time analytics engine, which continuously maintains metadata about capacity usage, file counts and access patterns across the entire namespace; this analytics metadata is itself part of the distributed store, so cluster-wide health affects both file access and the accuracy of reported capacity and usage data.
Qumulo presents a single namespace to clients over NFS, SMB and S3, meaning corruption or inconsistency introduced at the SBS layer can surface identically across all three protocols since they share the same underlying protected store.
Protocols and formats: NFSv3 / NFSv4.1, SMB2/SMB3, S3 (object access to the same namespace), REST API
- Data protection is implemented through distributed erasure-coding-style protection across nodes within the Scalable Block Store, sized according to cluster configuration rather than fixed RAID levels.
- Both file data and Qumulo's real-time analytics metadata reside within the same protected store, so metadata damage can affect capacity reporting even where file data itself remains intact.
Failure Scenarios
Logical failures
- Cluster quorum loss following multiple simultaneous node failures
- Scalable Block Store metadata corruption after an interrupted upgrade
- Accidental snapshot or file/directory deletion within the namespace
- Cloud Native Qumulo instance or underlying cloud volume misconfiguration
- Failed cluster expansion or node replacement leaving inconsistent placement metadata
Hardware failures
- Multiple node or drive failures exceeding the cluster's configured protection level
- Network fabric failure isolating nodes during a rebuild
- Node hardware failure during an active cluster expansion or node swap
- Cloud infrastructure failures affecting underlying volumes for Cloud Native Qumulo
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
Can data be recovered from a single Qumulo node?
Generally not in isolation, since file data and metadata are distributed across the cluster via the Scalable Block Store; a meaningful evaluation typically needs access to a representative set of cluster nodes.
Is Cloud Native Qumulo recovery different from on-premises Qumulo?
The Qumulo Core software and its data structures are the same; the main difference is that the underlying storage sits on cloud infrastructure rather than physical drives, which changes how media is preserved and accessed.
Does incorrect capacity reporting mean data is lost?
Not necessarily — since analytics metadata and file data share the same protected store, inconsistent reporting can indicate metadata-level issues that warrant evaluation without file data necessarily being unrecoverable.