We occasionally hear from customers running Cloud Native Qumulo (CNQ) on Microsoft Azure: "Our data lives in Azure Blob storage — so can we just use Azure's native backup and versioning tools to protect it?"
The short answer is no, and understanding why is the foundation of a sound protection strategy for CNQ. That's the starting point for our new technical whitepaper, "Backup & Security Reference Architecture: Cloud Native Qumulo (CNQ) on Microsoft Azure."
Why This Document Exists
CNQ's architecture is what makes it fast, scalable, and cost-efficient: compute and storage are fully disaggregated, with stateless VMs handling caching and I/O while a persistent, elastically scalable data tier lives directly in Azure Blob storage accounts. That separation is a strength for performance and elasticity — but it also means the data sitting in those Blob accounts isn't just a set of ordinary files. It's stored in Qumulo's proprietary, compressed, and encrypted object format.
That has a direct and important consequence: Azure Blob storage cannot serve as an independently restorable backup boundary for CNQ. Native Azure features like blob versioning or WORM immutability don't — and shouldn't — apply here. Applying them wouldn't create a usable backup; it could actually interfere with how Qumulo manages its own objects.
This whitepaper exists to draw a clear line between two things that are often conflated:
Protecting the data itself — which has to happen at the Qumulo layer, using native snapshots, replication, and (optionally) supported third-party backup integrations.
Securing the surrounding Azure infrastructure — identity, network, encryption, deletion protection, and logging — which is governed through native Azure controls.
Both matter. Neither substitutes for the other.
What's Inside
The reference architecture walks through the full protection model layer by layer:
Why the persistent (Blob) tier isn't a backup boundary — the specific technical reasons (proprietary object format, no supported restore path, cache-tier consistency, and lack of atomic cross-account point-in-time coordination) that rule out Blob-native protection.
The layered data-protection model — locked, immutable Qumulo snapshots as the primary defense against ransomware and accidental or malicious deletion, backed by continuous, incremental-forever replication to an off-cluster DR target in a separate subscription.
Recovery objectives by scenario — practical RPO/RTO guidance for everything from accidental file deletion to full site or subscription loss, plus summarized recovery playbooks for each.
Third-party backup integration — where and how tools like Commvault, Cohesity, Veeam, and Rubrik fit in as a complementary (not primary) layer, including the networking requirements for Qumulo's SnapDiff-based change tracking.
Ransomware protection — how Qumulo NeuralProtect adds inline, real-time threat detection and automated isolation at the data-plane layer, working alongside snapshots and backups rather than replacing them.
Securing the Azure environment itself — least-privilege identity with PIM-gated elevation, layered deletion protection so no single administrator can destroy storage, customer-managed encryption keys, private networking, and audit logging designed to survive a compromised admin account.
A threat-to-control mapping — a straightforward table connecting specific risks (rogue admin, ransomware, region loss, key compromise) to the controls that address them, useful for board or audit conversations.
Who Should Read This
This document is written for cloud and security architects who are designing, deploying, or auditing CNQ environments on Azure — particularly those in regulated industries where recoverability has to be demonstrable, not just assumed. It's also useful context for anyone evaluating third-party backup products alongside Qumulo, since it clarifies exactly what role those products should (and shouldn't) play.
The Big Takeaway
Data protection and infrastructure security are related but distinct problems, and CNQ's architecture requires treating them that way. Locked snapshots and replication protect your data. Azure governance — identity, network, encryption, and deletion controls — protects the infrastructure around it. Get both right, and you have a defense-in-depth posture where no single failure, misconfiguration, or compromised credential can take down your file system.
Read the full document to see how the pieces fit together, and to get the specific configuration guidance — Terraform variables, lock behaviors, PIM setup, and networking ports — needed to implement it in your own environment.
The whitepaper was written by Paul Johnson, Senior Director of Sales Engineering, and Justin Botticelli, Senior Systems Engineer.