Alternatives

This page explains what platform engineers and SREs typically use instead of a dedicated Kubernetes-native DR operator — and why those alternatives impose tradeoffs that Trilio Site Recovery is designed to remove. Understanding the alternatives helps you evaluate whether Site Recovery fits your environment and justify the architectural decisions it makes.

The problem space

Disaster recovery for KubeVirt VirtualMachines running on OpenShift requires protecting persistent block storage, coordinating VM lifecycle across two clusters, and providing a reliable, auditable failover mechanism. Teams reach for different tools depending on what they already operate. Each approach covers part of the problem; none covers all of it without custom integration work.

Storage-layer snapshot and replication tools

CSI snapshot and replication

OpenShift ships CSI snapshotting (VolumeSnapshot, VolumeSnapshotContent) and some storage vendors expose CSI replication interfaces. Teams use these to take periodic snapshots of VM PVCs and either retain them locally or replicate them to a second cluster.

What this gives you: point-in-time recovery, vendor-supported backup, integration with existing storage infrastructure.

What it does not give you:

• Continuous block replication with a defined RPO. Snapshots are periodic; data written between snapshots is lost.
• Any awareness of VM state. The snapshot is a PVC copy; nothing coordinates the VM shutdown, quiesces the guest OS, or orders the PVC snapshots of a multi-disk VM so they are crash-consistent.
• A failover controller. You recover by manually creating PVCs from snapshots on the DR cluster and redefining the VM — there is no CR to patch, no phase to watch, and no rollback.
• A test-failover path. Validating recoverability requires spinning up VMs manually from snapshot clones, in isolation, and tearing them down afterward — all by hand.

Storage-vendor replication (for example, NetApp SnapMirror, Pure Active Cluster, Ceph RBD mirroring)

Many enterprise storage arrays support synchronous or asynchronous replication at the volume level, presenting the replicated volume as readable on the secondary site.

What this gives you: mature, hardware-accelerated replication with vendor SLAs; often synchronous (zero data loss).

What it does not give you:

• Kubernetes-native orchestration. Failing over a replicated volume requires storage-admin steps outside Kubernetes — promote the replica, remount the volume, update PV/PVC bindings — none of which are Kubernetes CRs.
• VM lifecycle coordination. The storage layer does not know which VMs are using a volume, in what order they should boot, or whether a VM is running on the source cluster.
• A unified control plane. You need separate tooling to manage credentials, track failover history, and observe replication health from within Kubernetes.
• OpenShift-integrated access control. Operators with kubectl access cannot initiate or inspect a failover without also having access to the storage admin interface.

Cluster-level backup and restore tools

Tools such as Velero back up Kubernetes object definitions (including PVCs via snapshots) and can restore them to a second cluster.

What this gives you: full namespace and object graph recovery; vendor support; works across cloud and on-premises.

What it does not give you:

• Continuous replication. Restore RTO is bounded by the time to restore every object, pull images, and resync storage — typically minutes to tens of minutes.
• Synchronous RPO. Backup-based recovery always loses at least the changes since the last backup.
• An active standby. There is no pre-provisioned, continuously synced replica ready to be promoted. The DR cluster is cold until a restore runs.
• VM-aware ordering. Restoring a multi-tier application requires the operator to define and enforce boot order, which is not a first-class concept in backup-restore tools.

Manual DRBD between clusters

DRBD itself is a kernel-level block replication protocol. Some teams configure DRBD manually between two clusters' worker nodes to replicate PVC backing devices.

What this gives you: synchronous, zero-RPO block replication; works with any storage class that exposes a block device.

What it does not give you:

• Lifecycle management. DRBD drbdadm configuration files, resource definitions, port assignments, and metadata devices must be maintained by hand or with custom automation for every protected VM. Adding or removing a VM means editing configuration files on every node.
• A Kubernetes-native control plane. There are no CRs to describe protection intent, no conditions to observe, and no failover controller to drive role changes across clusters.
• Credential management. Cross-cluster API access must be provisioned and rotated manually.
• Test failover. Spinning up isolated VM copies from DRBD snapshots and fencing them from the production network requires significant custom automation.
• Admission control. Nothing prevents a protected VM from being migrated or its node drained, which would break the DRBD resource binding.

Stretched cluster and active-active topologies

Some teams address DR by treating two data center locations as a single stretched cluster — either a true multi-zone cluster or a federation layer.

What this gives you: transparent failover at the infrastructure level; workloads survive node failures without operator intervention.

What it does not give you:

• Protection from cluster-level failures. A stretched cluster is still one control plane; a split-brain or control-plane failure affects the whole cluster, not just one site.
• OpenShift Virtualization support. KubeVirt VMs using local PVCs cannot survive a node failure in a stretched cluster unless the storage is also stretched — which reintroduces all the storage-layer complexity described above.
• Audit and compliance. A stretched cluster does not emit failover events, RPO metrics, or test-failover results that can be presented to a compliance auditor.

Note: Trilio Site Recovery does not implement active-active topologies. Every protected zone has exactly two workload clusters — one active (primary) and one standby (DR) — and every failover is initiated explicitly by creating a FailoverRequest CR. Automatic failover is not performed.

GitOps-only approaches

Some teams maintain a GitOps repository that describes both clusters' desired state and switch active workloads by merging a PR that points the active cluster at the DR site.

What this gives you: full declarative control; audit trail in Git; no additional runtime components.

What it does not give you:

• Storage consistency. Switching which cluster runs a VM does not replicate the block devices. Unless storage replication is already in place and the DR-side PVCs are current, the VM starts from stale data.
• Coordinated shutdown. GitOps tooling reconciles desired state but does not wait for a VM to stop on the source cluster before starting it on the target cluster. Running the same VM on both clusters simultaneously causes data corruption for any VM with a writable PVC.
• RPO measurement. Git does not know whether the DR-side storage is in sync; there is no replication monitor to report out-of-sync bytes or current lag.

Summary comparison

Site Recovery is designed for teams that already run OpenShift Virtualization on two clusters and need a solution that is CRD-driven, integrates with their existing RBAC and GitOps workflows, and produces auditable DR records — without requiring them to operate a separate storage admin plane or write custom orchestration code.

• ProtectionZone — The top-level CR that registers a pair of workload clusters and selects the DRBD storage backend. Understanding the zone model clarifies how Site Recovery maps onto the two-cluster topology this page describes.
• ProtectionGroup and ProtectionRequest — The CRs that declare which VMs to protect and group them for coordinated failover, addressing the VM lifecycle coordination gap identified in the alternatives above.
• ReplicationGroupStatus and RPOEvent — The observability CRs that provide continuous RPO measurement, filling the monitoring gap that storage-vendor tools address only partially.
• TestFailover — The non-disruptive DR validation mechanism that most alternatives require custom automation to replicate.
• FailoverRequest — The CR that initiates a planned or unplanned failover; every failover is explicitly operator-initiated, not automatic.