A Technical Architecture for Resilience Without Lock-In

At a Glance

Key Takeaways

Section 01

Introduction

Data continuity used to be a "solved" problem. A VMware shop ran VMware-integrated protection, scheduled backups using that vendor's tooling, and tracked recovery against a single set of APIs. That model assumed two things that no longer hold. First, that the underlying infrastructure would stay stable across the depreciation cycle of the hardware. Second, that the cost of staying with that infrastructure would stay predictable.

Both assumptions broke in the same eighteen-month window. The teams handling this well are not waiting for a perfect cutover. They are choosing a destination platform and managing a transition that runs in parallel with production.

The infrastructure choice is only part of the answer. A team that exits VMware to a new platform still has to protect data, retain it for compliance, and recover it after a ransomware event. During the transition window, the team will run two hypervisors at once. A backup tier that only knows how to talk to one of them adds a second migration project on top of the first. The organizations getting this right treat the data protection tier as its own architectural decision, not a hand-me-down from the virtualization choice.

This paper presents a technical architecture for end-to-end data continuity that holds together during a hypervisor transition and stays durable after it. The architecture rests on two layers of protection that operate independently and reinforce each other. VergeOS handles the infrastructure layer, providing real-time resilience against hardware failure and operational error. The data protection layer is provided by a backup vendor that supports the source and destination hypervisors. Storware Backup and Recovery is the validated partner for that role.

Reference

Key Terms

Section 02

The Transition Reality

Most VMware customers in 2026 are considering running at least two hypervisors. The pattern is straightforward. The team selects a destination platform, begins migrating workloads, and runs both stacks in parallel until the migration completes. Depending on the size of the environment, the destination platform, and the migration strategy, the parallel-operation window can run for months or longer.

A workload-by-workload move is the rule rather than the exception. Critical workloads with deep VMware dependencies tend to migrate last because of NSX rules, custom backup hooks, vendor support contracts, and operational muscle memory. Tier-two workloads such as standard Linux and Windows servers, dev and test environments, and batch processing migrate first because the dependencies are simpler. The result is a transition window in which production data exists on the old hypervisor, the new hypervisor, or both at once.

This is the window where data protection design matters most. A backup tier that requires a separate product for each hypervisor produces operational drag at the worst possible time. The team is already running two infrastructure platforms. Adding two backup tools, two recovery procedures, and two retention policies multiplies the work. A backup vendor that handles both the source and the destination hypervisor with the same management plane removes that burden. The same Server, the same policy model, and the same recovery workflow apply to both sides of the migration.

"Heterogeneous environments are the norm now, not the exception."— Paweł Mączka, CTO, Storware. April 2026.⁴

The architectural point is simple. A backup vendor that supports a wide set of hypervisors is built for the transition window. The breadth of supported platforms means the team's chosen migration path is supported regardless of which destination platform they pick.

Section 03

The Two-Layer Protection Model

A single-product approach to data protection typically fails one of two tests. Infrastructure-only protection lives inside the virtualization platform. It handles hardware failure and operational continuity well, but offers no compliance retention, no air-gapped immutability, and limited defense against ransomware that targets the production cluster itself. Backup-only protection lives in a traditional backup vendor without integrated infrastructure resilience. It takes minutes to hours to recover a workload after a hardware event and depends entirely on backup scheduling for any meaningful protection.

The architecture that survives both modes places independent layers at each level of the stack.

VergeOS adds three more capabilities that matter for the data protection conversation. ioClone produces fully independent snapshots of entire VergeOS instances, specific virtual data centers, or individual VMs. Unlike redirect-on-write snapshots that hold dependencies on the parent, ioClone snapshots are independent objects that can be operated on without compromising the source. Global inline deduplication runs across the entire cluster, which keeps snapshot and RF operations from consuming duplicate capacity. ioReplicate provides asynchronous replication between instances, with the same deduplication advantage applied to wire transfers, enabling many-to-one disaster recovery configurations.

The two-stage backup architecture shapes what kinds of recovery are possible. Stage one collects data from the protected hypervisor and stages it on a Storware Node. Stage two transfers the staged data to the final repository. The repository may be NFS or SMB storage, S3 or Azure Blob object storage, Dell PowerProtect Data Domain via DD Boost, tape, or any combination of those targets. Synthetic forever-incremental backup is supported on file-system destinations, which means the backup chain consolidates without requiring repeated full backups. The practical effect is that long-term retention does not produce a linear growth in backup window or storage consumption.

Section 04

The VergeOS Architecture in Detail

VergeOS is software-defined infrastructure that integrates compute, storage, networking, and virtualization in a single operating system. It runs on standard x86 servers and treats the cluster as a single platform rather than a stack of individually licensed components. Three architectural choices distinguish it from hyperconverged and three-tier alternatives.

Single Code Base

Data availability, storage, network, and virtualization functions share the same kernel and the same memory space. Upgrades happen at the platform level rather than as coordinated multi-vendor windows. There is no separate storage array, no external SAN, no network overlay layered on top of an unrelated hypervisor. The simplification this produces is most evident at three points in the operational lifecycle. Deployment is one, where a new node is automatically absorbed into the cluster. Upgrade is another, where a single upgrade moves all functions forward together. Troubleshooting is the third, where a single set of logs and a single support relationship cover the entire stack.

Global File System

Storage in VergeOS is a clustered file system that spans all nodes contributing storage. Other nodes can be set to contribute only compute resources. VMs write to that file system directly, which means the protection target is the file system itself rather than a separately provisioned storage volume. This matters for backup integration because the backup vendor's Node, when deployed as a VM inside the cluster, has direct access to the storage layer through standard protocols.

Resilience Model

RF provides distributed data protection equivalent to a software-defined RAID across nodes. ioGuardian serves data during failures rather than treating failures as recovery events to be handled after the fact. Global inline deduplication compresses both production data and snapshots. ioClone produces independent snapshots that backup software can read without disturbing the production VM. ioReplicate produces cluster-to-cluster replication with deduplication-aware wire transfers.

These choices produce a platform that handles a broad range of failure modes without external help. Drive failure, node failure, network partition, accidental power loss, and several classes of operator error are all handled by the platform. The backup tier is not the first line of defense for any of these events. The backup tier is the long-term retention layer and the recovery layer for events the platform cannot detect, primarily logical corruption and slow-crawl ransomware.

Section 05

The Reference Implementation: Storware Integration with VergeOS

The Storware integration with VergeOS is direct. It is documented in both vendors' product guides, supported on VergeOS 4.13 and higher with Storware Backup and Recovery 7 and higher, and runs in production today. The integration uses native VergeOS export mechanisms rather than a custom plug-in or a wrapper around generic KVM tooling.

Deployment Model

1. NAS ServiceRuns inside the VergeOS cluster, providing an NFSv4 share that the Storware Node uses for data import and export.
2. Storware NodeDeployed as a VM in the cluster or as an external system with network access to the NAS service. Performs backup and restore operations.
3. Storware ServerCan run anywhere with network access to the Node. Manages policies, schedules, and the user interface.

Backup Workflow

The backup workflow uses VergeOS ioClone snapshots as the backup source. When a backup job runs, the Storware Node directs VergeOS to produce a snapshot of the target VM, then reads the snapshot through the NFS share and transfers the data to the backup destination. Changed block tracking identifies only the changed blocks since the last backup, which means incremental jobs transfer dramatically less data than full backups. Synthetic forever-incremental support means subsequent full backups can be constructed at the destination from the chain of incrementals, removing the need for periodic full re-runs against production.

Recovery Workflow

The recovery workflow runs in reverse. The Storware Node mounts the backup destination, identifies the recovery point, and writes the recovered data through the NFS share back into the VergeOS cluster. Granular recovery options include file-level restoration and full VM restoration. Instant restore capabilities, in which a VM boots from a backup share while the full restore runs in the background, work because the global file system absorbs the temporary storage domain without requiring a separate provisioning step.

Section 06

Recovery Across the Transition

A migration from one hypervisor to another produces a recovery scenario that many architectures handle poorly. A workload protected on the source hypervisor needs to be recovered onto the destination hypervisor. The reasons vary. The migration plan calls for protecting a VMware VM, then restoring it onto the new platform as part of the cutover. A datacenter event takes the source platform offline mid-migration and the recovery target is the partially-built destination cluster. A testing requirement spins up production data on the destination cluster before the cutover commits.

A backup tier that only knows how to recover into the same hypervisor it backed up from cannot do this kind of work. A multi-hypervisor backup vendor can. Storware supports cross-hypervisor recovery for several platform pairs through V2V conversion, including VMware to OpenStack and several KVM-based combinations. The full set of supported cross-hypervisor paths varies by version, and an architect designing for this scenario should validate the specific pair against the current Storware release notes. The architectural point is that the design exists.

For VergeOS specifically, the recovery story benefits from the platform's broad hardware support. VergeOS runs on most x86 hardware purchased in the last six years, which means a recovery cluster does not require a hardware refresh to come online. A team running VMware on existing hardware can build a parallel VergeOS cluster on the same or even different hardware family, recover protected VMs onto that cluster through Storware, and validate the recovery before committing to migration. The data path during this kind of staged recovery is the same one used in production, so the operation is not a one-time procedure that the team learns once and forgets.

Section 07

Ransomware Resilience as an Architectural Property

Ransomware has reshaped what backup means. The numbers explain why the architecture has to change.

Sophos data from 2024 independently put the targeting rate at 94 percent, with 39 percent of backup repositories completely lost during attacks.⁷ The implication: a backup that lives in the same trust domain as production has been compromised by definition once an attacker reaches the production system. Sixty percent of organizations believe they can recover within hours of an incident. Only 35 percent actually do.⁹

The two-layer architecture described in this paper produces ransomware resilience as a property of the design rather than as an add-on feature. VergeOS supports immutable snapshots at the platform layer through ioClone. These snapshots cannot be modified by an attacker who reaches the production cluster, because their construction is independent of the parent VM and they exist as read-only objects within the platform. The backup tier adds a second immutability layer through immutable storage targets, including S3 object lock, Data Domain retention lock, and similar mechanisms on supported targets.

The two layers protect against different attack patterns. An attacker who reaches the production cluster and corrupts running VMs encounters ioClone snapshots that cannot be modified, providing a recovery point inside the cluster itself. An attacker who reaches further and attempts to corrupt the backup tier encounters immutable storage targets that cannot be modified, providing a recovery point outside the cluster. The difference in recovery time between the two is significant. Recovery from an ioClone snapshot is near-instant because the data is already inside the cluster. Recovery from the backup tier is slower but provides the long-term retention horizon that compliance and forensic analysis require.

Section 08

Operational Considerations

Three operational topics deserve specific attention from an architect designing this kind of environment.

Sizing and Capacity Planning

Sizing must account for both layers. VergeOS sizing follows standard cluster planning, with consideration for RF2 overhead, snapshot retention, and dedupe ratios. Backup sizing depends on backup window, retention horizon, and the deduplication characteristics of the chosen destination. The NAS service inside VergeOS should be sized to match the throughput of the Storware Node, typically starting at 8 cores and 12 GB of RAM and scaling upward. Multi-Node Storware deployments allow throughput to scale horizontally for clusters above a certain size, with the threshold typically falling around 200 to 300 protected VMs, depending on backup window requirements.

Licensing Economics

Licensing economics stack cleanly. VergeOS licenses are per-host, so workload density does not increase license costs. Storware operates on a universal license model that covers all supported platforms, so protecting both the source and destination hypervisors during migration does not produce an additional license fee.¹⁰ The result is that the architecture rewards consolidation on the infrastructure side and removes a billing barrier from the transition window. Compared to a per-VM-licensed hypervisor combined with a per-platform-licensed backup product, the combined cost is consistently lower as VM density increases.

Testing Cadence

Testing cadence is the operational difference between an architecture that works on paper and one that works under pressure. The 25-point gap between expected and actual recovery times is the cost of skipped rehearsal. The recommendation is monthly recovery testing for both layers. Use ioClone snapshots to validate the in-cluster recovery path. Use Storware restores to validate the backup-tier recovery path. Both operations are non-disruptive when run against a non-production target, which means the team can test without affecting workload availability. An organization that rehearses recovery monthly reaches its stated RTO targets at a measurably higher rate than one that tests annually.

Section 09

Who Does What: VergeOS and Storware Role Comparison

The two-layer architecture works because each product owns its layer. The table below maps each data continuity role to the product that handles it. Some roles overlap by design, since defense in depth requires both layers to address the same class of threat from different angles. Where overlap exists, the table identifies the primary owner and the supporting role.

Section 10

Conclusion

The data continuity problem in 2026 is no longer a single-product procurement decision. The infrastructure stack is being rebuilt under transition pressure. The data protection tier needs to span the source and destination platforms during that transition. The cost of getting either layer wrong is measured in budget cycles rather than weekly outages. The architecture that survives this environment places independent protection at each level and treats the transition window as a planned operational state rather than an emergency.

VergeOS provides the destination infrastructure with integrated compute, storage, and virtualization, real-time resilience through RF and ioGuardian, immutable snapshots through ioClone, and global deduplication that makes both production and protection economical. The data protection layer, validated against Storware Backup and Recovery, provides native VergeOS integration, deep VMware support for the source side of the migration, two-stage backup with extensive destination flexibility, and immutable storage targets for ransomware-resistant retention. The two layers deliver end-to-end data continuity throughout the migration and remain durable after it completes.

For architects evaluating this design, the practical next step is a paired proof-of-concept. Stand up a small VergeOS cluster on existing hardware. Deploy a Storware Server and Node against that cluster. Protect a VMware VM, recover it onto VergeOS through Storware, and validate the workflow end-to-end. The components are designed to come up quickly, and the architecture is much easier to evaluate by running it than by reading about it. The customer who spends a week with the running system will know more about whether it fits the environment than any document can communicate.

Data continuity in a transition world rewards architects who design for the move and punishes those who treat it as an event. Protect the data the same way before, during, and after.

Common Questions

Frequently Asked Questions