Alternatives

This page describes what platform engineering and SRE teams typically use for Kubernetes VM disaster recovery before adopting Trilio Site Recovery, and why those approaches fall short of the RPO and RTO targets that production VM workloads require. Understanding the alternatives helps you evaluate where Trilio Site Recovery fits in your recovery strategy and what trade-offs you are accepting or eliminating.

The traditional DR landscape for Kubernetes VM workloads

Before purpose-built Kubernetes DR operators existed, teams protecting KubeVirt or OpenShift Virtualization workloads had to assemble recovery capabilities from tools designed for adjacent problems. None of these tools were built around the CRD-driven, storage-layer replication model that Trilio Site Recovery uses, and each imposes a different set of constraints on RPO, RTO, and operational complexity.

Backup-and-restore tools

Tools such as Velero (with restic or Kopia) and similar backup operators protect Kubernetes workloads by periodically snapshotting PVC contents and cluster state to an object store. On a disaster, you restore from the most recent snapshot.

Where they fall short for VM workloads:

• RPO is bounded by the backup schedule. A backup that runs every 30 minutes means up to 30 minutes of data loss in a disaster. Most production schedules run hourly or less frequently, putting practical RPO at 60 minutes or more. Trilio Site Recovery uses DRBD Protocol C synchronous replication, which acknowledges a write only after it is committed on both the primary and DR clusters, giving RPO = 0.
• RTO depends on restore throughput. Restoring a large VM's disk image from object storage is bounded by network bandwidth and storage write speed. RTOs of 1–4 hours are common for multi-hundred-gigabyte VM disks. Trilio Site Recovery promotes already-replicated DRBD volumes on the DR cluster, so the data is already there at failover time.
• No continuous replication. Between backup windows, your DR cluster has no current copy of the data. If the primary cluster fails mid-window, the working set since the last backup is lost.
• Application consistency is not guaranteed at the storage layer. Crash-consistent snapshots may leave database or application state requiring manual recovery steps after restore.

Backup tools remain useful for point-in-time recovery, longer-term retention, and protecting workloads that do not require zero RPO. They are not a substitute for continuous replication when your SLA demands RPO = 0.

Storage-level replication without an orchestration layer

Some teams configure DRBD, Rook/Ceph mirroring, or array-based replication directly, without a Kubernetes operator to manage the DR lifecycle.

Where this falls short:

• Manual failover is error-prone and slow. Without an operator watching FailoverRequest CRDs, an engineer must manually promote DRBD volumes, update PVC bindings, restart VMs in the correct boot order, and verify application health. Each step is a place where a mistake under pressure extends RTO or causes data corruption.
• No GitOps integration. Failover decisions cannot be expressed as Kubernetes objects, reviewed in pull requests, or driven by automation pipelines.
• No quorum arbitration. Without a neutral quorum cluster running the management plane, split-brain scenarios during a network partition require manual intervention to resolve safely.
• No test failover. Verifying DR readiness means either a real failover (which is disruptive) or a manual, ad-hoc test with no standardized cleanup path.

Trilio Site Recovery wraps DRBD with the failover-controller, protection-controller, and test-failover-controller reconcilers running on the quorum cluster, all driven by CRDs. The FailoverRequest and TestFailover CRDs make every DR operation auditable, repeatable, and automatable.

Cloud-provider DR services

Hyperscaler DR services (AWS Elastic Disaster Recovery, Azure Site Recovery, and similar) provide continuous block-level replication and orchestrated failover for VM workloads running on their platforms.

Where they fall short for on-premises or hybrid Kubernetes environments:

• Cloud lock-in. These services replicate into the provider's own infrastructure and assume both sides are within the same provider's ecosystem. Cross-cloud or on-premises-to-cloud topologies require significant architectural compromise.
• No Kubernetes-native control plane. Failover is driven through provider-specific consoles or proprietary APIs, not through Kubernetes CRDs. GitOps workflows and oc-based automation are not native capabilities.
• KubeVirt is not the target workload model. These services are designed for virtual machines on provider-managed hypervisors, not for KubeVirt VMs whose disks are Kubernetes PVCs. PVC lifecycle, boot order, and VM startup are not concepts these tools model.

Cluster-federation and active-active approaches

Some teams attempt active-active or active-passive cluster federation, distributing workloads across both sites simultaneously so that a site failure causes only a traffic shift rather than a failover.

Where this falls short:

• Stateful VM workloads are fundamentally incompatible with active-active. A KubeVirt VM running on two clusters simultaneously would require distributed locking, conflict resolution, and application-level awareness of dual-primary state — none of which KubeVirt or most guest applications provide.
• Complexity scales with workload count. Every VM that participates in the active-active topology requires individual placement and network policy management across both clusters.
• Storage synchronization remains unsolved. Federation addresses control-plane distribution, not storage-layer replication. You still need a mechanism to keep PVC contents consistent across sites.

Trilio Site Recovery uses a primary-plus-DR model (one cluster active, one cluster passive with replicated volumes), which is the correct model for stateful VM workloads that cannot safely run simultaneously on two clusters.

Operator-native snapshot-based DR

Some Kubernetes operators use VolumeSnapshot APIs to take periodic snapshots of PVCs and ship them to the DR cluster for restore on failover.

Where this falls short:

• Snapshot shipping reintroduces RPO windows. Even if snapshots are taken frequently, the DR cluster holds data only as current as the most recently shipped snapshot.
• Restore on failover extends RTO. Unlike DRBD, which keeps a live replica ready to promote, snapshot-based DR requires the DR cluster to provision PVCs and restore data before VMs can start.
• Cross-cluster snapshot transport is not standardized. Moving snapshots between clusters requires object storage intermediaries, version compatibility, and manual or custom-built pipeline logic.

Summary: where Trilio Site Recovery fits

Trilio Site Recovery is the correct choice when your requirements are RPO = 0, GitOps-driven DR operations, non-disruptive DR validation, and protection of KubeVirt or OpenShift Virtualization VMs on OpenShift 4.17 or later. It is not a backup tool and does not replace point-in-time recovery or longer-term retention capabilities — those remain valid use cases for backup-and-restore tools running alongside it.

• Plan and verify infrastructure — Before deploying Trilio Site Recovery, confirm your three-cluster topology (quorum, primary, DR), DRBD kernel modules, and network prerequisites meet the requirements that make RPO = 0 replication possible.
• Configure cross-cluster replication — Understand how the ProtectionZone controller automatically provisions the DRBDReplicationPolicy and what Protocol C synchronous replication means for your network latency budget (sub-50ms RTT required between primary and DR worker nodes).
• Protect virtual machines — Walk through creating a ProtectionRequest CR and tracking a VM through the Pending → Protected phase lifecycle.
• Run a test failover — Use the TestFailover CR to validate DR readiness non-disruptively, without affecting production VMs or requiring a real failover event.
• Verify replication health — Use ReplicationGroupStatus and RPOEvent CRDs to confirm that DRBD replication is Healthy and Consistent before you need it.