If you work in IT operations or data protection, this past week felt like a live-fire stress test — even if your own servers stayed green.
Within a span of 48 hours, two massive, unrelated outages brought modern commerce and travel to a standstill. First, a global Microsoft 365 disruption locked millions of knowledge workers out of Outlook, Teams, and Copilot. Almost immediately afterward, a communications failure grounded flights across the entire United States as the Federal Aviation Administration (FAA) issued a nationwide ground stop.
On paper, these two environments couldn’t be more different. One is a planetary-scale, cloud-native SaaS platform built on modern microservices; the other relies heavily on aging legacy hardware and decades-old telecommunications infrastructure. Yet, looking at both events through the lens of a senior backup administrator, the root lessons are strikingly identical.
Neither outage was caused by a sophisticated nation-state ransomware gang. One stemmed from modern cloud infrastructure and configuration complexity; the other came down to traffic overload and router data inconsistencies on legacy lines. Together, they expose the most dangerous blind spots in enterprise resilience today.
The M365 Lesson: SaaS Availability Is Not Data Recoverability
For years, backup admins have fought an uphill battle against a persistent myth in the C-suite: “We moved to Microsoft 365, so Microsoft handles our backups now.”
Microsoft runs one of the most resilient cloud architectures on the planet, complete with native geo-redundancy across global regions. However, platform availability is not the same thing as operational continuity or independent recoverability.
When a major SaaS tenant goes dark, organizations without independent, third-party SaaS backups realize they have zero out-of-band access to their own operational lifeblood. If Exchange or SharePoint is unreachable for hours, can your legal, finance, or incident response teams still search, export, and access critical historical emails and contracts? If your data lives exclusively inside the vendor’s ecosystem, the answer is no.
This is exactly the gap Commvault’s SaaSRecover addresses for M365 — independent, third-party protection for Exchange Online, OneDrive, SharePoint, and Teams with flexible restore options including point-in-time, in-place, out-of-place, and PST/CAB export. Backups run every 8 hours with forever-incremental scheduling, and compliance lock ensures immutability so data can’t be deleted or retention reduced.
Even worse, this week highlighted a classic operational trap: storing your Incident Response (IR) plans inside the very platform that just went down. If your disaster recovery runbooks, vendor escalation numbers, and emergency communication trees live inside SharePoint or Teams, you cannot read the playbook telling you what to do when M365 is offline.
The FAA Lesson: Technical Debt and the Change Management Trap
While the M365 outage showed the limits of hyperscale cloud abstraction, the FAA ground stop demonstrated the opposite extreme: the compounding risk of deferred modernization.
Every senior infrastructure admin recognizes the “keep the lights on” budget cycle. When capital gets tight, organizations patch aging systems rather than re-architecting them. In the backup world, this looks like nursing unsupported disk arrays, unpatched media servers, or brittle network routes along for “just one more fiscal year.” Eventually, technical debt comes due — usually at the worst possible moment.
Furthermore, both events underscore an uncomfortable truth that every veteran administrator knows: routine change management is a bigger statistical threat to uptime than cyberattacks. Whether it is a subtle router update, a DNS misconfiguration, or an unisolated traffic spike cascading across redundant paths, internal changes routinely bypass the very high-availability safeguards designed to prevent them. If a single network bottleneck or configuration error can take down both your primary and secondary paths, you do not have true isolation — you just have two ways to fail at the same time.
This is why Commvault AirGap matters. It enforces true isolation: one-way outbound communication from the AirGap cluster only, pull-based replication, minimal port exposure, and immediate isolation after replication completes. Control logic resides within the AirGap cluster, not the CommServe — so a production-side failure can’t cascade into your recovery tier.
Neither of this week’s failures involved AI, and it’s worth saying that plainly. But look at what did cause them: a change someone made on purpose, inside a system too complex for any one person to hold in their head. Now think about who is making changes in your environment next year. Agents are already modifying configurations, granting access, and moving data, and they do it faster than any change advisory board can review. This week’s failure mode is the one we’ll see again, except the change will land in seconds and nobody will have filed a ticket for it. That’s why discovery and rollback have to be continuous rather than scheduled.
What Continuous Recovery Looks Like on Monday Morning.
You don’t need a massive budget overhaul to apply the lessons from this week’s twin outages. Use these events as a catalyst to audit four critical areas of your resilience posture. These aren’t precautions, this is what continuous recovery looks like at the console:
- Move Your Runbooks Out-of-Band — Pull your disaster recovery plans, network diagrams, vendor support contacts, and break-glass credentials out of M365 and SharePoint. Maintain an immutable, offline copy — or store them in a completely independent repository that does not rely on your primary cloud tenant. Commvault’s compliance lock and AirGap provide that immutable, isolated storage layer.
- Decouple Backup Authentication from Production SSO — Having an independent third-party backup for M365 is great, unless the backup portal relies exclusively on Entra ID (Azure AD) Single Sign-On to let you log in. Ensure your backup administrators have dedicated, MFA-protected local break-glass credentials so you can still access and export data during an identity provider outage.
- Audit Your Blast-Radius Isolation — Look closely at the network and management planes connecting your production environment to your backup storage. Verify that a cascading routing error, DNS failure, or broadcast storm in production cannot saturate or sever access to your recovery tier. This is where Commvault Cleanroom adds value — it provides an isolated recovery environment, either cloud-based in AWS/Azure or on-premises with an air-gapped Commvault Grid (formerly HyperScale X) vault, where you can recover and validate data without risking reinfection of production.
- Retire Your “FAA-Era” Backup Debt — Identify the oldest, most fragile piece of hardware or legacy software in your data protection stack. Use this week’s headlines to build a clear business case to leadership: paying down technical debt now is vastly cheaper than explaining an extended outage later. Consolidating to a unified, integrated platform reduces technical debt and lowers the risk of human error.
Final Thought
Even tech giants and federal agencies with world-class engineers hit architectural edge cases. The point isn’t to assign blame. It’s that the hardest hours come after the alarm, when you’re working out what changed and what you can still trust. Resilience is being able to answer that question fast, every time, because you were already watching.
