Backup Isn’t Enough Anymore

Why ransomware, DORA, NIS2 and the Broadcom shock have rewritten the rules for enterprise backup — and what an expert-driven recovery platform looks like in 2026.

Backup systems used to live in a quiet corner of the data centre. They were insurance — the thing you ran at night, occasionally tested, and hoped never to need under real pressure. That era is over. Today, backup platforms are doing work that used to belong to firewalls, EDR agents and SIEM stacks: detecting tampering, enforcing immutability, isolating data from compromised networks, and proving to auditors that recovery is not a slide deck but a measurable operational capability.

Customers evaluating backup software now arrive with questions they used to reserve for security vendors. The shift is not cosmetic. It is structural — driven by ransomware economics, by regulators who assume the breach will happen, and by cyber insurers who increasingly dictate the architecture before they will write the policy.

This article walks through that shift from the perspective of an engineer who has watched it play out in production, and explains where Storware Backup and Recovery sits in the new landscape — from hardened Linux foundations to OpenStack edge cases to the question European boards are quietly asking again: under whose jurisdiction does our data actually live?

From “Do You Have a Backup?” to “Is Your Backup Survivable?”

For most of the last two decades, backup procurement decisions came down to a familiar checklist: capacity, RTO/RPO numbers, compatibility with the existing hypervisor estate, and the licensing model. Those criteria still matter. They no longer decide the deal.

Ransomware operators figured out the easy lesson first. The fastest way to extract a ransom is not to encrypt the production workload — it is to destroy the backup catalogue, then encrypt the production workload. Almost every published incident report from the last three years describes the same pre-encryption phase: enumerate backup infrastructure, harvest credentials, delete or corrupt repositories, then trigger the payload. By the time the security team is paged, the recovery path is already gone.

That changed the question the buyer asks. “Do you have a backup?” has been replaced by “Is your backup safe from the attacker who already has Domain Admin?” The honest answer for most legacy estates is uncomfortable, and that discomfort is what is driving the current wave of replacement projects.

Why Regulators Now Assume the Breach Will Happen

European regulation has moved in the same direction, only faster. DORA in financial services and NIS2 across critical sectors both abandon the implicit assumption that strong preventative controls are enough. They start from the premise that a serious incident will eventually occur and that the regulated entity must be able to prove — not assert — its ability to restore operations within a defined window.

This subtly but decisively reframes audit conversations. Auditors used to ask whether protective controls were in place. Now they ask whether the organisation can keep functioning if those controls fail. A SOC that detects and contains an intrusion two hours after initial access has done its job correctly — but if databases were encrypted in those two hours and restoration takes three weeks, the bank or hospital in question has still experienced a catastrophic incident. Operational, reputational, financial — all three.

So organisations are quietly retiring the old strategy of “we will make sure nobody gets in” and replacing it with something less heroic but more honest: assume a successful attack at some point, and engineer the environment so the business survives it. Backup is no longer the last line of defence. It is the proof that the business can keep working under pressure.

The shift in audit conversations is the clearest signal. Five years ago they wanted to see your controls. Today they want to see your last successful restore test, the timestamp on it, and what you measured. — Paweł Mączka, CTO, Storware

Cyber Insurers Are Quietly Becoming Backup Architects

A second pressure point sits with the cyber insurance market. After two years of large payouts, underwriters have stopped treating backup as a vague checkbox and started treating it as part of the underwriting model. Policies increasingly require specific architectural commitments before a quote is even issued.

In practice, that list usually includes:

• Offline or logically isolated copies that cannot be reached from the production network.
• Documented, regularly executed restore tests — not just successful backup jobs.
• Network separation of the backup repository, with its own authentication boundary.
• Multi-factor authentication on the backup console itself, not just the corporate IdP.
• Immutability or retention locks for a defined window, measured against the average dwell time of ransomware operators.

It is now common for prospects to arrive with the insurer’s checklist in hand and ask the backup vendor to map features against each line. That conversation favours platforms designed for this world from the start over platforms retrofitting it now.

The New Backup Vocabulary: Immutability, Anomaly Detection, Air Gap

Vendor messaging has moved with the market. Terms that were obscure five years ago — cyber resilient backup, data security posture management, anomaly detection inside backup streams — now appear on most product pages. Some of it is marketing varnish. Some of it is real engineering.

The features that genuinely matter under attack are concrete and testable:

• Immutability: backup copies that cannot be modified or deleted before their retention window expires, enforced at the filesystem or object-store level, not at the application layer where an admin token can override it.
• Multi-factor authentication on the management console: because the attacker’s first move after credential theft is to log into the backup UI and shorten retention to zero.
• Air-gapped or isolated copies: data that is not network-reachable in the steady state and only becomes addressable during a restore.
• Anomaly detection in backup streams: change-rate and entropy signals that flag the early stages of mass encryption before the catalogue is corrupted.
• Pre-restore scanning: the ability to scan a backup image for indicators of compromise before mounting it back into production, so you do not re-infect yourself during recovery.

These are no longer optional. They are the minimum bar for any platform calling itself enterprise-ready in 2026.

Freedom of Choice: Backup for a Post-VMware World

Storware took an unfashionable bet early on. While most competitors specialised in two or three dominant hypervisors — VMware and Microsoft Hyper-V owned the bulk of the global virtualisation market — Storware Backup and Recovery was designed from the start as a multi-hypervisor platform with native, agentless protection across more than a dozen virtualisation stacks. For years, that breadth looked like over-engineering. Why protect every hypervisor when two of them held the market?

The Broadcom acquisition of VMware answered the question. Gartner analyses suggest that a clear majority of legacy VMware customers now intend to move at least part of their estate elsewhere. For smaller environments, Proxmox VE and XCP-ng are the natural exit routes. For genuine enterprise and managed service providers, the realistic alternative at scale is OpenStack — flexible, vendor-neutral, and considerably more complex than what most teams left behind.

Storware was already there. The platform did not have to be rebuilt under deadline pressure to support the new shape of the market. That is a quiet advantage that becomes loud when a customer is twelve months into a migration plan and discovers their backup vendor still does not protect the target platform.

A note on scope, because it gets mis-stated: Storware provides V2V migration from VMware to OpenStack specifically. For exits to Proxmox or other targets, the right move is the platform’s own importer (Proxmox has one built in). Storware’s role in those projects is protection across the transition — backing up both the old and new environments simultaneously while the migration tooling does the moving. Migration is fast; backup keeps it safe.

Why OpenStack Breaks Most Backup Tools

OpenStack is the environment that gives backup architects more headaches than any other. The market reflects this: only a small handful of professional options exist. Trilio, Storware, and OEM products built on the Storware engine and sold under the names of larger vendors. That is essentially the field.

The reason is structural. In VMware or Hyper-V, the administrator works inside well-defined boundaries. Deviation from the reference architecture is possible but narrow. In OpenStack, those boundaries effectively do not exist. Administrators are gods of their own infrastructure — free to combine Cinder drivers, Neutron topologies, Nova compute backends, Ceph storage layouts and identity arrangements in dozens of permutations. Every deployment is, in practice, its own dialect of the platform. Many of them are built against the grain of the official reference manuals, and they still need to be protected.

The architectural choice that matters here is whether the backup product imposes its own assumptions on the environment, or adapts to whatever the environment actually looks like. Storware took the second route. The platform discovers and maps OpenStack resources dynamically and protects them even in deployments that are eccentric by design. That sounds abstract until you are the team running the eccentric deployment. Then it is the difference between a working backup and a permanent open ticket.

Hardened Linux: The Foundation Under Everything Else

Storware deliberately built its software on Linux. This was not a technical limitation. It was a strategic decision shaped by the threat landscape — roughly 95% of cyberattacks target Windows environments, which makes a Windows-based backup server an unhelpful place to put the keys to your last line of defence.

On top of Linux sits a hardened, purpose-built distribution that forms the foundation of the security stack. Several further layers are stacked on it:

• Immutability backed by the XFS filesystem.
• Encryption of data at rest.
• Multi-factor authentication on management interfaces.
• SSO integration via Keycloak.
• Tape support as a true cold-storage tier.
• The Isolator feature (Storware’s air-gap implementation): after a backup job completes, the secondary copy becomes unreachable on the network and reappears only when a restore is initiated. An attacker with full access to the production environment cannot see it, let alone delete it.

What “Hardened” Actually Means

Operating-system hardening is a misused word. In practice, it means removing everything an attacker could use as a foothold. For a Linux backup appliance, the concrete list is:

• Unnecessary services disabled — the system runs only what the backup software strictly requires.
• Strict process privilege separation — every process can do its job and nothing else.
• Unused network ports and protocols closed at the kernel level.
• No facility for installing third-party software on the appliance.
• Filesystem integrity verification — any unauthorised change is detected.

On Storware appliances, the constraints go further still — down into the microcode of the hardware components. Swap the approved network card for a different one and the system will refuse to start. Standard Linux is general-purpose by design and rewards flexibility. Hardened Linux is deliberately stripped of that flexibility so that the appliance cannot be used in any way other than the one the manufacturer intended.

The same discipline applies regardless of geography. European appliances are assembled, tested and provisioned by Storware’s own team before shipping. For deployments in Asia and the United States, a local partner assembles the hardware to a strict specification and Storware performs the hardened OS installation and configuration remotely. Nobody outside Storware has access to the operating system or the security layer underneath it.

Data Sovereignty: Where Your Backups Live, and Whose Laws They Answer To

For European organisations, technical hardening is only half the conversation. The other half is jurisdictional. The U.S. CLOUD Act permits American authorities to compel U.S.-headquartered providers to produce data they hold — including data stored on servers physically located in the European Union. For sectors under DORA, NIS2 and sector-specific data-residency obligations, that is not a theoretical concern.

Storware addresses this by splitting cloud partners into two clearly delineated segments. The first comprises global providers from any jurisdiction, including the United States and Canada — the right choice when the customer’s posture genuinely is global. The second is reserved for European-only cloud providers — OVHcloud, Nordic and Dutch operators among others — with no capital or operational ties to entities outside the EU. The customer chooses which segment fits their compliance posture; the platform does not force the question.

The technical layer of that approach is implemented through cooperation with the Portuguese provider Vault. In this model, data sent to the cloud is automatically split and distributed via erasure coding across at least two or three independent European data centres. Compromising a single node yields no recoverable data; an authorised user reconstructs the dataset from the remaining fragments without friction.

The entire stack — source code written and maintained in Poland, technical support delivered from the EU, cloud infrastructure resident in European data centres — can stay within European jurisdiction end-to-end. That is no longer an unusual ask. On the global backup market in 2026, it is one of the fastest-growing reasons customers move.

What This Means for the Backup Conversation in 2026

The buyer’s question has shifted permanently. The features that decide enterprise deals today are not the ones that decided them five years ago. The credible backup platform in 2026 has to demonstrate, in order:

• That the recovery path survives an attacker who already controls the production environment.
• That it can prove this to an auditor, an insurer and a regulator in language each of them recognises.
• That it protects the actual hypervisor estate the customer is moving to — not the one they are moving away from.
• That the jurisdiction under which the data is held matches the compliance posture of the business.

Storware Backup and Recovery was built around those four answers from the start. The hardened Linux foundation, the Isolator air-gap, immutability on XFS, MFA on the console, the multi-hypervisor breadth that already covers the post-VMware world, and the European jurisdictional stack from source code to cloud — none of it was retrofitted under pressure. It is the product of a deliberate, slightly unfashionable bet made several years before the market caught up.

The companies asking the new questions tend to be the ones that have already lived through an incident or watched a peer live through one. They are not in the market for marketing language. They are in the market for proof. That is, in the end, what an expert-driven backup platform is supposed to deliver — proven, scalable protection across the most demanding environments, simplified down to something a small team can actually operate under pressure.

Frequently Asked Questions

What is a cyber-resilient backup, and how does it differ from a traditional backup?

A traditional backup is judged by whether a recovery point exists. A cyber-resilient backup is judged by whether that recovery point can survive an attacker who already has administrative access to the environment. The difference is enforced through immutability, isolation, MFA on the backup console itself, anomaly detection inside backup streams, and pre-restore malware scanning — features designed for the assumption that the breach has already happened.

How do DORA and NIS2 change backup requirements?

Both frameworks shift the audit focus from preventative controls to demonstrable recovery capability. Auditors expect documented restore tests with timestamps, defined recovery windows tied to business processes, isolated copies that survive a network-wide compromise, and an authentication boundary around the backup platform that does not rely solely on the corporate identity provider. Backup becomes part of the operational resilience evidence, not a separate IT function.

Is Storware Backup and Recovery a good alternative for organisations leaving VMware?

Yes — and the reason is structural rather than tactical. Storware Backup and Recovery has supported multi-hypervisor protection since well before the Broadcom transition. Customers moving workloads to OpenStack, Proxmox VE, XCP-ng, OpenShift Virtualization, KVM-based platforms or other targets can protect both the source and the destination during the migration window from a single platform. For the specific case of VMware-to-OpenStack, Storware also provides V2V migration. For other targets, the native importer of the destination platform is usually the right tool, with Storware providing protection on both sides.

Why is OpenStack so hard to back up, and how does Storware handle it?

OpenStack’s flexibility is its strength and its complication. Every deployment combines Cinder, Neutron, Nova, Keystone and storage layers in slightly different ways, and many production environments deviate from the reference architecture deliberately. A backup platform that assumes a fixed shape will fail in those environments. Storware Backup and Recovery discovers and maps the environment dynamically and adapts to the deployment as it actually is, rather than the deployment the manual describes.

Does the U.S. CLOUD Act affect data stored in EU data centres?

It can. The CLOUD Act permits U.S. authorities to compel U.S.-headquartered providers to produce data they hold, including data physically resident in the European Union. Organisations whose compliance posture requires hard jurisdictional boundaries — typically financial services, public sector, healthcare, defence and increasingly anything under NIS2 — need a stack whose providers sit outside the CLOUD Act perimeter. Storware offers that as an explicit option: an end-to-end European stack from source code to cloud storage.

What does “hardened Linux” actually mean on a Storware appliance?

It means a purpose-built Linux distribution with everything the backup software does not strictly need removed or disabled — unused services, unused ports, the ability to install third-party software, anything that an attacker could repurpose as a foothold. On Storware appliances the constraints extend to the hardware microcode itself, so swapping an unapproved network card halts the system. The aim is a platform that can only be used the way it was designed to be used.

See it under pressure, not just in a slide.

If your last restore test pre-dates your last board conversation about ransomware, the gap is worth closing. Book a working session with the Storware team and we will walk through your current backup architecture against the DORA / NIS2 / insurer checklist — and show you exactly which gaps a cyber-resilient platform closes, and which ones it does not.

→ Book a meeting: storware.eu/book-meeting