Alternatives

This page describes the tools and approaches that platform engineering and SRE teams typically use for virtual machine disaster recovery on OpenShift before adopting Trilio Site Recovery—and explains where those approaches fall short for synchronous, block-level VM protection. Understanding these alternatives helps you evaluate the trade-offs in RPO, RTO, operational complexity, and Kubernetes-native integration that motivated Trilio Site Recovery's design.

The DR problem for VM workloads on OpenShift

OpenShift Virtualization (CNV) runs KubeVirt virtual machines on Kubernetes infrastructure, but Kubernetes itself provides no built-in cross-cluster disaster recovery. When a cluster or datacenter fails, you need an external mechanism to replicate VM state to a secondary site and restart workloads there with acceptable data loss and downtime. The tools teams reach for fall into several categories, each with meaningful limitations when applied to VM workloads at enterprise scale.

Backup and restore tools

The most common starting point is a Kubernetes-native backup tool such as Velero (with object-storage backends) or similar products in the TrilioData ecosystem. These tools snapshot PersistentVolumeClaims and Kubernetes object state on a schedule, export them to object storage, and can restore them to a target cluster on demand.

Where this falls short for DR:

• RPO is bounded by schedule frequency. Snapshots typically run every 15–60 minutes, meaning up to an hour of data loss is possible in a failure scenario. For databases, transaction-heavy VMs, or any workload where data changes continuously, this is often unacceptable.
• RTO is manual and slow. Restore workflows require an operator to detect the failure, initiate a restore job, wait for PVC data to transfer from object storage, and then start VMs. End-to-end recovery typically takes 1–4 hours, not minutes.
• No continuous replication. Between snapshots, new writes on the primary cluster have no copy on the DR side. A failure at minute 59 of a 60-minute backup window loses nearly an hour of data.
• Object storage as the transport layer introduces transfer bandwidth, egress costs, and restore latency that grow with VM disk sizes.

Backup tools remain valuable for point-in-time recovery, compliance archiving, and accidental-deletion scenarios. They are complementary to—not a replacement for—continuous replication-based DR.

Storage-layer replication managed outside Kubernetes

Some teams use storage array or cloud-block-storage replication features (for example, Ceph RBD mirroring, NetApp SnapMirror, or EMC SRDF) to replicate PVC backing devices between sites. Others run DRBD directly on virtual or bare-metal nodes without a Kubernetes operator managing the lifecycle.

Where this falls short:

• No Kubernetes integration. Replication state, failover triggers, and VM orchestration all live outside the Kubernetes API. There are no CRDs to query, no GitOps workflows, and no kubectl surface for DR operations. SREs must log into separate management consoles or run bespoke scripts.
• Manual VM orchestration during failover. Even if storage replication is in place, someone must stop VMs on the primary, promote volumes on the DR side, update DNS or load balancer entries, and start VMs in the correct order with the correct PVCs attached. This is error-prone and slow under pressure.
• No test failover without production impact. Validating DR readiness typically requires a full failover test, which takes the primary offline or requires manual snapshot handling to avoid data divergence.
• Operational burden scales with VM count. Managing DRBD resources, endpoints, and promotion state per VM across two clusters without a controller requires significant scripting and ongoing maintenance.

OpenShift GitOps and cluster configuration replication

ArgoCD and OpenShift GitOps can replicate Kubernetes manifests—including VirtualMachine objects—from a primary cluster to a DR cluster. Some teams treat this as a lightweight DR strategy: keep the DR cluster in sync with the primary's Git-managed configuration so VMs can be created there quickly after a failure.

Where this falls short:

• Manifests are not data. GitOps synchronizes the definition of a VM, not the contents of its disks. A VM that boots on the DR cluster from a fresh PVC or a stale snapshot does not have the data it had at the moment of failure.
• No storage replication. GitOps has no mechanism to replicate PVC data between clusters. You still need a separate data-plane replication solution.
• RPO and RTO are not improved. Recovering data still depends on backup/restore or manual volume promotion workflows.

GitOps is a valuable tool for managing the declarative configuration of DR infrastructure—including Trilio Site Recovery's own CRD manifests—but is not a substitute for continuous data replication.

Hypervisor-layer replication (VMware vSphere Replication, etc.)

Organizations migrating from VMware to OpenShift Virtualization sometimes ask whether vSphere Replication or Site Recovery Manager can continue to protect VMs running on KubeVirt. They cannot: these tools require the vSphere hypervisor stack and have no integration with KubeVirt, OpenShift APIs, or DRBD-backed storage.

Similarly, cloud provider native VM replication services (AWS DRS, Azure Site Recovery) target their own hypervisors and cannot manage KubeVirt VMs on OpenShift clusters.

Snapshot-based application-consistent DR products

Some products offer "application-aware" DR by quiescing databases or running pre/post-snapshot hooks before taking a consistent snapshot. This improves backup quality but does not change the fundamental RPO/RTO characteristics: recovery still depends on snapshot frequency and restore throughput.

Summary of trade-offs

The key differentiators Trilio Site Recovery provides over these alternatives are continuous block-level replication at the storage layer (eliminating the backup-window RPO problem), a fully automated failover orchestration path driven by Kubernetes CRDs (eliminating manual VM promotion steps), and non-disruptive test failovers via the TestFailover CRD that validate DR readiness without touching production workloads.

The following example illustrates the contrast between a backup-restore workflow and a Trilio Site Recovery failover workflow, so you can see concretely what changes.

Backup-restore DR trigger (manual, minutes to hours)

With a backup-only approach, recovering a VM after a primary-cluster failure looks like this:

# 1. Operator detects failure and manually initiates restore
# 2. Wait for PVC data to transfer from object storage to DR cluster
# 3. Patch VM manifests to reference restored PVCs
# 4. Start VMs manually
# (No CRD, no automation, no progress tracking)

Expected outcome: VMs start on the DR cluster with data as of the last scheduled snapshot—potentially 15–60 minutes stale. Total elapsed time: 1–4 hours.

Trilio Site Recovery planned failover (automated, minutes)

With Trilio Site Recovery and continuous DRBD replication already in place, the same transition is a single CRD apply:

kubectl --kubeconfig $KUBECONFIG_QUORUM apply -f - <<'EOF'
apiVersion: siterecovery.trilio.io/v1alpha1
kind: FailoverRequest
metadata:
  name: production-failover
  namespace: dr-prod
spec:
  protectionGroupRef:
    name: production-vms
  targetCluster: dr-cluster
  failoverType: planned
EOF

Watch automated progress:

kubectl --kubeconfig $KUBECONFIG_QUORUM get failoverrequest production-failover -n dr-prod -w

Expected output:

NAME                   STATUS       AGE
production-failover    Pending      2s
production-failover    InProgress   8s
production-failover    Completed    4m31s

Expected outcome: VMs start on the DR cluster with zero data loss (Protocol C) or seconds of data loss (Protocol A). Total elapsed time: 3–8 minutes with no manual steps.

Non-disruptive DR test (no production impact)

With backup tools, testing DR readiness requires scheduling a restore to a non-production cluster and manually verifying it. With Trilio Site Recovery, a TestFailover does this automatically:

kubectl --kubeconfig $KUBECONFIG_QUORUM apply -f - <<'EOF'
apiVersion: siterecovery.trilio.io/v1alpha1
kind: TestFailover
metadata:
  name: quarterly-dr-test
  namespace: dr-prod
spec:
  protectionGroupRef:
    name: production-vms
  cleanupPolicy: Manual
  retentionTime: 2h
EOF

Expected output (watching phases):

NAME                STATUS              AGE
quarterly-dr-test   CreatingSnapshots   10s
quarterly-dr-test   CreatingVolumes     45s
quarterly-dr-test   CreatingVMs         1m12s
quarterly-dr-test   VerifyingData       2m30s
quarterly-dr-test   Succeeded           3m05s

Production VMs are never interrupted. Cleanup deletes all test resources when you delete the TestFailover CR.

• What is Trilio Site Recovery — overview of how DRBD-based block replication solves the RPO and RTO gaps described on this page
• Deployment models — how the DRBD Operator model maps onto two- or three-cluster OpenShift topologies
• Protocol C and Protocol A replication — trade-offs between synchronous (RPO=0) and asynchronous (seconds RPO) replication modes
• ProtectionRequest — how to place a single VM under continuous block-level protection in the DRBD Operator model
• FailoverRequest — planned and unplanned failover CRD reference
• TestFailover — non-disruptive DR validation using volume snapshots
• RPOEvent and ReplicationGroupStatus — monitoring replication lag and health to ensure DR readiness between tests