Alternatives

This page explains what platform engineering and SRE teams typically use for site recovery and disaster recovery before adopting Trilio Site Recovery, and why those approaches impose constraints that a storage-layer, CRD-driven operator is designed to address. Understanding the alternatives helps you evaluate the trade-offs clearly and set accurate expectations for what Trilio Site Recovery changes—and what it does not change—about your DR posture.

Backup-and-restore tools

The most common approach to DR for VM workloads on Kubernetes is a scheduled backup tool that snapshots PVCs or VM state at regular intervals and writes those snapshots to object storage. Trilio for Kubernetes, Velero, and similar tools fall into this category.

The fundamental constraint of this model is the backup interval itself. Because protection is point-in-time, the recovery point objective (RPO) is bounded by how frequently backups run—typically 15 to 60 minutes. Between two backup windows, any writes to a protected VM are unprotected. Restoring from a backup also requires transferring data from object storage into a new cluster, which drives recovery time objectives (RTO) into the 1–4 hour range depending on dataset size and network throughput.

This model works well when RPO measured in minutes and RTO measured in hours is acceptable—for development environments, batch workloads, or applications that tolerate data loss and extended unavailability. It is a poor fit for stateful, latency-sensitive applications where data written seconds before a failure must survive.

Trilio Site Recovery operates at the storage layer instead of the application or snapshot layer. DRBD replicates every write block-by-block to the DR cluster before acknowledging it to the guest OS, which makes RPO structurally zero rather than interval-dependent. This is not a configuration choice: Protocol C synchronous replication is the only supported mode, and RPO is not tunable.

Storage-native replication

Some storage platforms—Ceph RBD mirroring, NetApp SnapMirror, Pure Storage ActiveDR—provide their own asynchronous or synchronous replication. These solutions are effective when all workloads share a single storage backend and that backend has native replication support.

The challenge on Kubernetes is heterogeneity. Clusters that mix storage classes, use node-local storage (TopoLVM, LVMS), or host VMs whose disks land on different backends cannot be protected by a single storage platform's replication feature. Storage-native replication also sits outside the Kubernetes API: triggering a failover, monitoring replication health, or running a DR drill requires out-of-band tools that are not composable with GitOps workflows or kubectl-driven automation.

Trilio Site Recovery uses DRBD as its replication engine and exposes every operation—protecting a VM, checking replication health, running a test failover, triggering a planned or unplanned failover—through Kubernetes Custom Resources in the siterecovery.trilio.io/v1alpha1 API group. DRBD is the only supported storage backend. Operations are initiated by creating or patching CRs (ProtectionRequest, FailoverRequest, TestFailover), which makes them composable with GitOps pipelines and auditable through standard Kubernetes tooling.

Manual or scripted failover runbooks

Many teams operate DR through a documented runbook: stop VMs on the primary, promote a storage replica, start VMs on the DR site. When practiced regularly this can achieve reliable RTO, but it has several structural weaknesses:

• Human error on a high-stress path. Failover runbooks are executed under time pressure, often outside business hours, by engineers who may not have run the procedure recently.
• No continuous validation. A runbook that was correct six months ago may not account for schema changes, new VMs, or modified boot dependencies. There is no automatic equivalent of a test failover.
• Coordination across clusters is manual. Determining which VMs to start, in what order, on which nodes requires reading state from multiple systems.

Trilio Site Recovery replaces the runbook for the mechanical steps. A planned failover is initiated by creating a FailoverRequest CR with failoverType: planned; the failover-controller handles VM shutdown on the primary, DRBD volume promotion on the DR cluster, and VM startup in dependency order. An unplanned failover uses failoverType: unplanned and force-promotes DRBD volumes without waiting for the primary to shut down gracefully. Neither operation happens automatically—every failover is initiated by a human or an automation creating a FailoverRequest.

Non-disruptive DR validation is provided by the TestFailover CR, which takes volume snapshots, starts test VMs in an isolated namespace, runs configurable reachability and HTTP health checks, and cleans up afterward. This replaces the need to schedule a full DR drill that takes production systems offline.

Active-active topologies

Some DR architectures aim for active-active operation: both sites serve traffic simultaneously, with synchronous or asynchronous replication keeping them consistent. This eliminates RTO entirely for a class of failures but requires application-level conflict resolution and is generally limited to stateless or specially designed stateful workloads.

Trilio Site Recovery does not implement an active-active topology. The model is active-standby: one cluster (the source) hosts running VMs and one cluster (the DR side) holds synchronized replicas that are promoted only on failover. This is enforced by DRBD's Primary/Secondary role assignment—a volume can only be written from one side at a time.

Multi-cluster federation tools

Tools such as KubeFed and its successors attempt to synchronize Kubernetes objects—Deployments, Services, ConfigMaps—across clusters. For stateless workloads this can approximate active-active or fast failover. For stateful workloads backed by PVCs, federation tools do not replicate the underlying block data: they replicate the PVC object, not its contents. Starting a VM from a federated PVC on the DR cluster starts it from whatever state the storage backend on that side contains, which is undefined unless a separate replication mechanism is also in place.

Trilio Site Recovery focuses specifically on the storage layer for KubeVirt/OpenShift Virtualization VMs. It does not federate Kubernetes objects, manage Services, or coordinate DNS across clusters. Those concerns remain with your network and cluster configuration.

Constraints that alternatives do not address

Two operational constraints are worth naming explicitly because alternative tools often paper over them:

Node pinning. A VM protected by Trilio Site Recovery is pinned to one node per cluster for the lifetime of the protection. Live migration and cold migration of a protected VM are denied by the admission webhook. Backup-and-restore tools and runbook-based DR do not impose this constraint, but they also do not maintain continuous block-level replication; the constraint is the mechanism by which sub-50ms RPO is achieved.

Latency requirement. Protocol C synchronous replication requires round-trip latency below approximately 50ms between primary and DR worker nodes. Backup-and-restore tools and asynchronous replication approaches have no latency requirement because they tolerate data lag. If your primary and DR sites are separated by more than 50ms RTT, synchronous replication is not viable for that topology, and the alternatives in this page—particularly scheduled backup tools or storage-native asynchronous replication—remain the appropriate choice.

• How Trilio Site Recovery works — Overview of the DRBD storage-layer replication model, the TSR-Manager cluster role, and the CRD-driven operations model.
• Plan and verify infrastructure — Prerequisites and network requirements, including the 50ms RTT constraint and the TCP 7000–8000 port range, that determine whether a given site topology is compatible with Protocol C synchronous replication.
• Protect virtual machines — How to create a ProtectionRequest and what the protection lifecycle phases mean.
• Run a test failover — How the TestFailover CR provides non-disruptive DR validation as an alternative to scheduled full DR drills.
• Execute a planned failover and Execute an unplanned failover — How FailoverRequest replaces manual runbook steps for the mechanical failover sequence.
• Verify replication health — How ReplicationGroupStatus and RPOEvent surface replication state continuously, replacing manual health checks.