--- title: Alternatives product: trilio-site-recovery-for-kubernetes-openshift-virtualization doc_type: concept version: feature-tsr-24 source: git2docs (code-derived, validation-filtered) canonical: https://git2docs.com/murali-balcha/docs/trilio-site-recovery-for-kubernetes-openshift-virtualization/site-recovery/alternatives --- # Alternatives _What teams use instead of this operator for Kubernetes disaster recovery_ ## Overview Platform teams protecting KubeVirt or OpenShift Virtualization workloads have several options beyond Site Recovery. Understanding what those alternatives offer — and where they fall short for Kubernetes-native VM disaster recovery — helps you justify architectural decisions, respond to procurement questions, and recognize which gaps Site Recovery was specifically designed to close. ## Content ## The landscape of Kubernetes DR for virtual machines Disaster recovery for virtual machines on Kubernetes sits at the intersection of two historically separate domains: VM-level DR (traditionally handled by hypervisor vendors) and cloud-native backup and recovery (handled by tools built for stateless workloads). Most available tools are strong in one domain but not both. Site Recovery was built to address this gap specifically for KubeVirt and OpenShift Virtualization environments. ## Hypervisor-native DR tools Tools such as VMware Site Recovery Manager and Zerto were designed for traditional hypervisor environments. When organizations migrate VMs to KubeVirt or OpenShift Virtualization, these tools lose visibility into the workload layer: they cannot manage Kubernetes CRDs, do not understand KubeVirt VirtualMachine objects, and cannot trigger failover through the Kubernetes control plane. Adapting them to a Kubernetes environment typically requires significant custom scripting and ongoing maintenance that grows as your cluster configuration changes. Site Recovery operates entirely within the Kubernetes API. Failover is declared with a `FailoverRequest` resource; protection state is tracked in `ProtectionGroup` and `ProtectionRequest` resources. Controllers continuously reconcile desired state, so your DR configuration stays consistent with your cluster without manual intervention. ## Velero and backup-oriented tools Velero and similar tools focus on backup and restore: they snapshot namespace resources and PVC data, store them externally, and restore them on demand. This model works well for stateless application recovery but has meaningful limitations for VM disaster recovery: - **RTO is measured in tens of minutes**, not the 3–8 minutes Site Recovery targets, because restore operations must transfer full volume data at recovery time rather than maintaining continuously synchronized replicas. - **RPO is bounded by your backup schedule** — hourly or daily snapshots create proportional data loss windows. Site Recovery's Protocol C (synchronous DRBD replication) achieves RPO=0 because every write is committed to both the primary and DR cluster before being acknowledged. - **Consistency across related VMs is not guaranteed** unless you carefully coordinate snapshot timing. Site Recovery's `ProtectionGroup` resource groups VMs so they fail over as a coordinated unit, preserving application-level consistency. - **Velero does not manage VM lifecycle**. It can restore a VirtualMachine manifest, but it does not orchestrate the stop-promote-start sequence required for a safe failover, and it has no concept of replication state or readiness. ## CSI-level replication Some storage vendors provide CSI-based volume replication between clusters. These solutions replicate at the storage level but leave the orchestration layer to you: you must build and maintain the logic to detect a failure, promote the DR replica, update DNS or load balancers, and restart VMs in the correct order. Each of these steps is a potential source of human error under the pressure of an actual incident. Site Recovery's `failover-controller` automates this entire sequence. When you create a `FailoverRequest`, the controller handles volume promotion, VM shutdown on the primary (for planned failovers), and VM startup on the DR cluster — including dependency ordering within a Protection Group. You get a single, auditable Kubernetes resource that tracks the entire operation's progress. ## OpenShift DR (ODF Metro-DR and Regional-DR) Red Hat OpenShift Data Foundation provides Metro-DR (synchronous, stretch cluster) and Regional-DR (asynchronous, hub-managed) capabilities for OpenShift workloads. These are well-integrated solutions for OpenShift Kubernetes applications but are designed primarily for container workloads using RWX or RWO PVCs bound to pods, not for KubeVirt virtual machines. OpenShift DR does not natively understand KubeVirt VirtualMachine lifecycle, does not coordinate VM-specific operations such as guest shutdown before volume promotion, and does not expose the VM-centric abstractions (ProtectionGroup, ProtectionRequest, TestFailover) that Site Recovery provides. If your environment is exclusively KubeVirt or OpenShift Virtualization and you need VM-aware orchestration, Site Recovery addresses that layer directly. ## Cluster-level replication and GitOps approaches Some teams use GitOps pipelines to maintain parallel cluster configurations and rely on re-deploying manifests as their recovery strategy. This approach works for stateless workloads where storage state can be rebuilt from source, but it does not address the core challenge of VM disaster recovery: the persistent disk data accumulated since the last deployment. Without continuous block-level replication, re-deploying a KubeVirt VM manifest recovers the configuration but not the data. Site Recovery's DRBD kernel-level replication keeps disk data continuously synchronized, so failover promotes an up-to-date replica rather than restoring from a stale snapshot or rebuilding from scratch. ## When alternatives may be appropriate Site Recovery is purpose-built for VM workloads on KubeVirt or OpenShift Virtualization with strong RTO and RPO requirements. There are cases where alternatives remain appropriate: - **Stateless container workloads** with no persistent state benefit from simpler multi-cluster routing tools or GitOps-based recovery rather than block-level replication. - **Long-retention backup requirements** — regulatory archiving of VM state over months or years — are better served by dedicated backup tools alongside Site Recovery rather than instead of it. - **Environments without KubeVirt** running only standard pod workloads do not need VM-aware failover orchestration. For any environment running production VMs on KubeVirt or OpenShift Virtualization where your RPO and RTO requirements are measured in minutes or seconds, Site Recovery's combination of continuous block replication, Kubernetes-native orchestration, and VM-lifecycle-aware failover addresses gaps that general-purpose tools leave open. ## Examples > **Note for reviewer:** This page is a concept/comparison page with no runnable commands of its own. The examples below illustrate the contrast between a manual recovery workflow and the Site Recovery declarative approach, to make the comparison concrete for readers. **Manual recovery without Site Recovery: volume promotion and VM restart require multiple uncoordinated steps** Without an orchestrating controller, a typical CSI-replication failover requires you to find and promote each volume replica, patch each VirtualMachine manifest to reference the new PVC, and start each VM — with no built-in sequencing or rollback. ```bash # Example of what you would do manually (not Site Recovery) # Step 1: Promote each replicated PVC on the DR cluster (varies by CSI driver) kubectl patch volumereplicationgroup my-vrg \ --type merge -p '{"spec":{"replicationState":"primary"}}' # Step 2: Patch each VM to reference the promoted PVC kubectl patch virtualmachine vm-web-server \ --type merge -p '{"spec":{"template":{"spec":{"volumes":[{"name":"disk0","persistentVolumeClaim":{"claimName":"promoted-pvc"}}]}}}}' # Step 3: Start each VM individually — no coordination with vm-database kubectl patch virtualmachine vm-web-server \ --type merge -p '{"spec":{"runStrategy":"Always"}}' # Repeat for every VM; handle failures manually ``` **With Site Recovery: declare intent and the controller handles the sequence** ```bash # Create a FailoverRequest — the failover-controller orchestrates # volume promotion, VM shutdown, and VM startup in the correct order kubectl apply -f - <<'EOF' apiVersion: siterecovery.trilio.io/v1alpha1 kind: FailoverRequest metadata: name: web-tier-failover namespace: dr-prod spec: protectionGroupRef: name: web-tier-pg failoverType: unplanned EOF # Watch the controller drive the operation to completion kubectl get failoverrequest web-tier-failover -n dr-prod -w ``` ``` # Expected output as the controller progresses through the sequence: NAME STATUS AGE web-tier-failover Pending 2s web-tier-failover Promoting 8s web-tier-failover Starting 45s web-tier-failover Succeeded 2m31s ``` ## Related concepts - **What is Site Recovery** — An overview of the operator's architecture, deployment models, and how DRBD replication relates to RPO and RTO targets. - **Protection Groups** — How to group VMs so they fail over together as a coordinated unit, addressing the cross-VM consistency gap in general-purpose tools. - **ProtectionRequest** — The DRBD Operator model's VM-level protection primitive, which automates the volume replication setup that manual approaches require you to script. - **Planned and unplanned failover** — How the `failover-controller` drives the failover sequence end-to-end, including the VM lifecycle steps that storage-only replication tools leave to you. - **Test failover** — How to validate DR readiness non-disruptively using the `TestFailover` resource, providing a verification capability that most alternative tools do not offer for VM workloads. - **RPO and RTO** — A deeper explanation of Protocol C synchronous replication and the 3–8 minute RTO target that Site Recovery is designed to meet.