Enterprise Backup Decision Framework

If you have landed here, your shortlist probably already exists. It usually reads some combination of Veeam, Rubrik, Cohesity and Commvault — the four names that surface in almost every enterprise backup discussion, every analyst grid and every late-night thread where a systems administrator asks strangers to validate a six-figure decision.

The problem is not the shortlist. These are capable platforms with real installed bases and real engineering behind them. The problem is that the comparison most teams run answers the wrong questions. It compares feature checklists and headline license prices, and then a year into production the costs that actually mattered turn out to have been nowhere on the spreadsheet.

This is not a “why you should pick us” article. It is a decision framework — the set of questions that separate a backup choice you will defend in three years from one you will quietly regret. Where Storware Backup and Recovery is a relevant answer to one of those questions, we will say so plainly. Everywhere else, the goal is to help you run a better evaluation, whatever you end up buying.

The shortlist is the trap, not the answer

Walk into most evaluations and the framing is already set: compare the contenders side by side, weight the features, total the license quotes, pick the winner. It feels rigorous. It is also where the real cost hides, because the line item on the quote is rarely the line item that breaks the budget.

Practitioners know this even when procurement does not. Ask anyone who has run a large environment for a few years where the money actually went, and the answer is almost never “the license.” It is the operational overhead — the engineers babysitting the platform, the professional-services engagements to get features working, the storage architecture nobody scoped, the migration that took three quarters instead of one.

“Everyone benchmarks the license fee because it is the number on the quote. Then you spend two years discovering the parts that were not on the quote — the data movers you have to feed, the consultants you have to keep on retainer, the hypervisor you bought last month that your backup vendor still does not support. The sticker price is the cheapest part of the decision. It is just the only part that is easy to compare.”

— Paweł Mączka, CEO, Storware

So before comparing products, it is worth being honest about what you are actually trying to optimise. The four questions below are the ones that tend to be decisive — and the ones a feature matrix tends to obscure.

Dimension 1 — Operational TCO: the cost that is not on the quote

Total cost of ownership in backup is dominated by operations, not acquisition. The relevant question is not “what does this cost to buy” but “what does this cost to run, every week, for the life of the contract.”

Two patterns drive most of the hidden overhead:

Data-mover and node sprawl. Architectures that depend on distributed media agents or proxy components to move data require those components to be sized, deployed, patched, monitored and load-balanced. In a large estate this becomes a standing operational tax. The more moving parts sit between your production data and your backup target, the more there is to maintain — and the more there is to break at 2 a.m.

Professional-services dependency. Some platforms are powerful precisely because they are deeply configurable, and that depth has a cost: you either staff for it with dedicated specialists, or you keep the vendor’s services organisation on retainer. There is a reason a meaningful share of certain vendors’ revenue comes from professional services rather than licenses. Deep configurability is a genuine strength for teams that have the people to wield it. For teams that do not, it is a recurring invoice.

How to test it before you buy: ask each vendor to quantify the steady-state operational footprint for your environment, not a reference architecture. How many components do you deploy and maintain? How many FTE-hours per week does a comparable customer spend administering the platform? What percentage of customers at your scale run without ongoing paid services? The answers, and the willingness to give them, are diagnostic.

Dimension 2 — Appliance or software: what you are really buying when you buy nodes

One of the most consequential and least examined choices is whether your backup platform is fundamentally a piece of software you run on infrastructure you control, or a set of appliances and nodes you buy, rack and depend on.

Appliance-led models have real advantages. A self-contained, vendor-supported stack that you do not have to architect yourself can be genuinely low-touch — many teams run such systems for years without intervention, and value the clean operational separation from the rest of the environment. That is a legitimate reason to choose them.

But the appliance model also embeds two long-term commitments worth surfacing explicitly. The first is a hardware refresh cycle and the capital and procurement overhead that comes with it. The second, and more subtle, is architectural lock-in: when the data movers, the index and the recovery logic are bound to specific nodes, your backup strategy is tied to that vendor’s hardware roadmap and pricing for the duration.

The software-first alternative inverts this. A platform that installs on standard Linux and uses your existing or commodity infrastructure for compute and storage keeps the architecture in your hands. Storware Backup and Recovery follows this model: it is software you deploy on infrastructure you own, with backup destinations of your choosing — local filesystems, S3-compatible object storage, tape libraries, the Storware Cloud, or an existing enterprise backup target used as a data mover. The point is not that software-first is universally better; it is that the appliance-versus-software decision is strategic, not cosmetic, and it deserves more scrutiny than it usually gets.

How to test it before you buy: map the full cost and commitment of the deployment model over the contract term, including hardware refresh, and ask what happens to your recovery capability if you want to change storage vendors, change hardware vendors, or move workloads between sites. A model that makes those changes easy is worth a premium; one that makes them painful is a cost you will pay later.

Dimension 3 — Multi-hypervisor continuity: protecting the environment you actually have

This is where shortlists most often quietly fail, because nearly every enterprise environment is heterogeneous and most backup platforms were built around an assumption of homogeneity.

The pattern is familiar: a platform that is excellent for VMware is adequate for one other hypervisor and weak or absent for the rest. Then your environment changes underneath the assumption. You add Nutanix AHV. A team stands up OpenStack or OpenShift Virtualization. The post-Broadcom licensing shock pushes a migration off VMware that nobody planned for two years ago. Suddenly the platform you chose for its VMware excellence is a poor fit for half your estate, and you are either running two backup products or accepting coverage gaps.

A second, sharper version of this problem shows up in environments where virtual machines move. When a VM is live-migrated between clusters, or fails over in a disaster-recovery scenario, some backup platforms treat the relocated VM as a brand-new object — breaking the backup chain, forcing a fresh full baseline, and consuming storage and backup windows that the dedupe math assumed it would never need. In a large, mobile environment this is not an edge case; it is a recurring operational wound.

Storware’s relevance here is its breadth. It protects VMware vSphere (ESXi 7.0 and 8.0), Microsoft Hyper-V, Nutanix AHV, OpenStack across all major distributions, OpenShift and OpenShift Virtualization, Proxmox, XCP-ng, Oracle Linux KVM, VergeOS, Scale Computing and others — under a single universal license rather than a separate SKU per platform. For VMware it is agentless via the vSphere APIs for Data Protection; for AHV it uses a proxy-VM model integrated with Prism Central and Changed Region Tracking; agents are added only where they earn their place, such as Hyper-V, file-level protection and application-consistent backups. The design assumption is heterogeneity, not a single hypervisor with bolt-ons.

What Storware does not do is let us hand-wave the VM-mobility question. Whether any platform — Storware included — preserves an incremental chain through a live cross-cluster move or a failover is precisely the kind of claim you should never take from a datasheet. It depends on your hypervisor, your topology and your specific failover mechanics. Make it a mandatory proof-of-concept test, not a checkbox.

How to test it before you buy: inventory every hypervisor and platform you run today and every one on your two-year roadmap, and confirm first-class support for each under one license. Then, in the PoC, deliberately move a protected VM between clusters and force a failover, and verify with your own eyes whether the backup chain survives or re-baselines. This single test separates marketing from reality faster than any feature grid.

Dimension 4 — Data sovereignty and immutability: where your data lives and what “immutable” really means

Two questions sit underneath this dimension, and both are increasingly non-negotiable for European organisations.

The first is jurisdiction. Where does your backup data physically reside, and whose law governs access to it? A backup copy held in a hyperscaler region that is operated by a U.S.-headquartered provider can fall under the reach of the U.S. CLOUD Act regardless of where the bytes sit — which can place it in direct tension with GDPR, and with the obligations now arriving under NIS2 and DORA. For regulated industries and public-sector bodies, “our DR copy is in someone else’s cloud under foreign jurisdiction” is no longer an acceptable shrug. It is an audit finding waiting to happen. This is exactly why teams increasingly rule out pure cloud-based DR-as-a-service on sovereignty grounds even when the economics look attractive. Learn more.

The second is the integrity of the recovery point itself. Ransomware operators now target backup repositories directly — industry research has put the share of attacks that attempt to compromise backups at well above 90%. That changes the requirement: a backup is only as good as its resistance to deletion and encryption by an attacker who already has administrative access. “Immutable” has become a marketing word, so it pays to ask what it means at the storage layer. Is it true write-once-read-many enforcement, retention lock, object-lock on S3-compatible targets, a genuine air gap that isolates the recovery point from the production network — or a setting that a sufficiently privileged attacker can simply switch off?

Storware’s position on both is deliberate. It is European software, deployed on infrastructure you control, with backup destinations you choose — including fully on-premises and air-gapped targets that keep your data under your jurisdiction. Its security model is vendor-independent and layered: IsoLayer air-gap isolation, immutable write-once backup destinations, retention lock, AES encryption in transit and at rest, RBAC, MFA via Keycloak, air-gapped tape targets and full audit trails suited to NIS2 and GDPR reporting. The architecture treats isolation as a property of the design rather than a feature flag.

How to test it before you buy: require each vendor to state, in writing, where backup data resides under each proposed deployment, which legal jurisdiction governs access, and exactly how immutability is enforced at the storage layer. Then ask the uncomfortable question: if an attacker obtains administrative credentials, what specifically prevents them from deleting or altering the backups? A clear, mechanism-level answer is the one you want.

A vendor-neutral proof-of-concept checklist

A feature matrix is a starting point, not a decision. The decision is made in a proof of concept that mirrors your real environment. Run one, and make every vendor on the shortlist — including any challenger you add — earn their claims against the same tests:

• Steady-state operations: measure the actual administrative effort and component count to run the platform for two weeks, not the demo-day happy path.
• Every platform you run: back up and restore on each hypervisor and workload type in your estate, under one license, including the ones on your roadmap.
• VM mobility: move a protected VM between clusters and force a failover; confirm whether the backup chain survives or re-baselines.
• Restore speed and granularity: time a full-VM restore, a file-level restore and an application-consistent restore — recovery, not backup, is what you are buying.
• Immutability under attack: attempt to delete or alter a backup with elevated privileges and confirm the protection actually holds.
• Sovereignty: verify in writing where data resides and under whose jurisdiction, for every deployment model proposed.
• Licensing at scale: model the cost at your real and projected scale, including every platform and every destination — small-print scaling clauses change decisions fast.
• Support response: open a real ticket during the PoC and measure what actually happens.

Comparison: the dimensions that usually decide it

Where Storware fits

Run the framework honestly and the shortlist sorts itself by your priorities. If your estate is single-hypervisor, your team is staffed for deep configuration, and a vendor appliance stack suits your operating model, one of the established names may well be the right answer. None of this is an argument that they are not.

Storware earns its place on the shortlist when the decisive dimensions are the ones above. It is built for the heterogeneous reality most enterprises actually run: many hypervisors under one universal license, software-first deployment on infrastructure you control rather than nodes you are tied to, European data sovereignty by design, and a layered, vendor-independent security model. It has been the open-source data protection specialist since 2015 and is positioned as the leading backup solution for OpenStack — not because heterogeneity is a marketing angle, but because the world is heterogeneous and the platform was built for that.

The world is heterogeneous, and the right backup platform is the one built for that reality — yours. Run the proof of concept. Test the questions that do not fit on a feature grid. Then decide.

If you want to see how Storware handles the dimensions above against your own environment, book a technical session with our team and bring your hardest PoC test.

Frequently asked questions