Part 3 of the “Compass Protects It All” Series
There’s a version of backup confidence that feels earned. Green job reports, reliable overnight runs, a clean restore test in last quarter’s DR exercise. From the inside, it can look like a problem solved.
Attackers see something very different. And increasingly, so does the data.
Veeam’s most recent Data Trust and Resilience Report found that 90% of security leaders were confident they could recover from a cyberattack within their recovery time objectives. In the same study, only 28% of ransomware victims actually recovered all their data over the past year.
That gap points back to architecture. Not training or process, but the foundational decisions about how data protection is designed and connected. The infrastructure choices IT leaders make in the next 12 months — what to renew, replace, or keep holding together with scripts and goodwill — will determine which side of that 28% their organizations land on for years to come.
One more number worth sitting with: 89% of ransomware attacks now target backup repositories directly, and only 32% of organizations use immutable storage, despite years of well-documented warnings. Attackers have learned that compromising your backups makes your recovery plan theoretical. They are counting on the fact that your backup infrastructure wasn’t designed with that in mind. In most cases, they’re right.
What’s Failing — and Why It’s Failing Now
Three patterns dominate enterprise backup environments today, and none of them were built for the world we’re operating in.
The first is the proprietary backup appliance. This model centers on closed hardware, vendor-controlled deduplication, and lifecycle progression tied to procurement schedules. Its design assumed that a dedicated physical appliance on the network provided a meaningful degree of isolation. That assumption was shaped by earlier threat models and has become increasingly difficult to sustain as attack techniques have evolved.
The second is the script library — IBM i save commands, BRMS automation, AIX cron jobs, PowerShell glue holding x86 and cloud together. Each script represents a person who might leave, an undocumented dependency, and a recovery run book that likely hasn’t been tested end-to-end in over a year. These approaches earn the “legacy” label not because they’re old, but because they were built for a threat environment that no longer exists — one where backup infrastructure wasn’t a primary target, audit trails were an afterthought, and no regulator expected you to prove recovery capability.
The third is the platform-by-platform point tool approach: one product for IBM Power, another for VMware, another for Microsoft 365, another for AWS. Each with its own console, access controls, patch cadence, and blind spots at the platform boundaries.
What makes all three genuinely dangerous today is hybrid workload sprawl. The modern estate isn't just on-premises and cloud — it's IBM Power and IBM i, VMware, x86, SaaS, and public cloud, each with its own backup requirements. IBM's 2026 X-Force Threat Intelligence Index found that vulnerability exploitation has become the leading cause of attacks. Every backup tool bolted on platform by platform is one more console, one more patch cadence, and one more set of credentials to defend — each expanding the attack surface while making coordinated management and recovery harder, not easier.
An organization running AIX, x86 VMs in vSphere, containers in OpenShift, Microsoft 365, and workloads across two clouds is typically managing five to eight backup tools simultaneously. That fragmentation limits unified reporting, complicates anomaly detection, and makes cross-platform recovery orchestration difficult to execute reliably.
When an auditor or an attacker shows up, the seams are where the exposure lives. Protecting hybrid environments requires rethinking the operating model for protection, not adding to it.
Five Principles That Will Still Matter in 2030
By the end of this decade, resilience will be judged less by intent and more by execution. These principles define the architectural choices that consistently separate organizations that can recover under pressure from those that struggle when assumptions break.
Resilience that isn’t tied to hardware refresh cycles. Tying your recovery capability to a proprietary appliance refresh cycle means your resilience evolves at the pace of capital expenditure. A software-defined control plane, delivered as a service, evolves continuously because threats don’t wait for your next procurement cycle.
One operating model across every platform you run. Environments spanning IBM Power, IBM i, AIX, x86, VMware, containers, SaaS, and multiple clouds benefit from a unified approach to protection, monitoring, and recovery. A shared policy engine, console, and access model enable consistent execution across platforms and simplify coordinated recovery.
Cyber resilience built into the data path. With backup systems frequently under direct attack, effective architectures extend beyond storage controls to include anomaly detection, automated response, and clean-room recovery workflows that validate data integrity before restoration. These elements support recovery outcomes measured by Mean Time to Clean Recovery, focusing on the reliability of restored data as well as recovery speed.
Policy-driven automation, not a script library. Recovery that depends on someone remembering which steps to execute under pressure introduces avoidable risk. Modern architectures define protection through policy, enforce it uniformly across environments, and adjust automatically as systems drift. Automation that exists only as a collection of scripts rarely survives real-world complexity.
Sovereignty and regulatory control as design decisions. Regulatory requirements such as DORA’s four‑hour incident reporting window, NIS2’s early warning obligations, and expanding data residency mandates across the EU, APAC, and U.S. sectors increasingly shape system design. Data location, access controls, and demonstrable recovery capability are now core architectural considerations that must be addressed upfront.
The Decision in Front of You
The next backup infrastructure decision your organization makes won’t be a routine refresh but a seven‑to‑ten‑year architectural commitment. This years-long process will be pressure‑tested by ransomware operators, who now achieve full domain encryption in under four hours; by regulators measuring resilience in hours rather than days; and by a hybrid environment that will only grow more complex.
Before that decision gets made, five questions are worth putting on the table at your next infrastructure review:
- Is our recovery capability tied to a hardware refresh cycle?
- Can we orchestrate recovery across IBM i, x86, and cloud from a single policy engine?
- Are our backups immutable — and are we monitoring backup data itself for anomalies?
- If a major incident were declared right now, could we report its data impact accurately within DORA's four-hour window — with evidence, not estimates?
- How many scripts would need to run, in the right order, by the right people, for our worst-case recovery to succeed?
The organizations that recover well in 2030 won’t necessarily be the ones with the largest backup budgets. They’ll be the ones making architecture decisions now — treating data protection as a discipline, not a collection of tools, and designing for recovery before the pressure arrives.
< Back to Blog