Intended Audience

This page describes who Trilio Site Recovery is designed for, what background knowledge you need to use it effectively, and what operational responsibilities it addresses. Understanding whether this product fits your role and environment helps you decide where to start and which workflows apply to your deployment.

Who This Product Is For

Trilio Site Recovery is built for platform engineers and site reliability engineers (SREs) who are responsible for the availability and recoverability of KubeVirt virtual machine workloads running on OpenShift clusters. If you design, operate, or are accountable for disaster recovery (DR) plans for virtualized workloads on Kubernetes, this product is intended for you.

It is not a general-purpose backup tool and does not address application-level data consistency beyond what lifecycle hooks provide. It is also not a self-service tool for application developers — the workflows it exposes (cluster registration, protection policy definition, failover execution) require cluster-level access and an understanding of Kubernetes storage and networking.

What Operational Problems It Addresses

Trilio Site Recovery automates the replication and failover of KubeVirt VirtualMachine objects and their persistent volumes across two geographically separate OpenShift clusters. Without a tool like this, recovering a virtual machine after a site outage typically involves manual steps: identifying which volumes need to be restored, promoting a standby replica, reconfiguring network identity, and restarting workloads in the correct order. Site Recovery replaces that runbook with declarative Kubernetes custom resources that can be driven by kubectl, GitOps tooling, or the TSR web console.

Specifically, Site Recovery addresses:

• Continuous block-level replication — DRBD Protocol C synchronous replication keeps a mirror of every protected VM's persistent volumes on the DR cluster. Because replication is synchronous, RPO is always zero: no writes are acknowledged on the primary until both sides confirm.
• Coordinated failover — A FailoverRequest custom resource triggers a planned or unplanned failover of all VMs in a ProtectionGroup to a specified target cluster. Every failover is initiated explicitly; nothing happens automatically.
• Non-disruptive DR validation — A TestFailover custom resource spins up isolated copies of protected VMs on the standby cluster using DRBD snapshots, inside a network-fenced namespace, without touching production VMs.
• Credential and access management — Zone credentials (kubeconfig Secrets) that grant the TSR-Manager orchestration access to each workload cluster are managed exclusively through the tsrctl CLI, with rotation and RBAC refresh supported without downtime.
• Observability — ReplicationGroupStatus and RPOEvent custom resources aggregate per-VM DRBD metrics and emit immutable audit records on every replication status transition, giving you a compliance-ready history of replication health.

Required Kubernetes Knowledge

This product assumes intermediate Kubernetes proficiency. You should be comfortable with the following before working through the installation and operations workflows:

• Custom Resource Definitions and kubectl — All DR operations are declared through CRDs in the siterecovery.trilio.io/v1alpha1 API group. You apply, patch, and inspect these resources with kubectl the same way you would any other Kubernetes object. If you have not worked with CRDs before, review the upstream Kubernetes documentation on custom resources first.
• Namespaces and RBAC — Site Recovery places TSR-Manager-side resources (ProtectionZone, ProtectionGroup, ProtectionRequest, and related CRs) in a dedicated dr-<name> namespace on the TSR-Manager cluster. Workload-side components (the workload control plane and DRBD node agent DaemonSet) are installed into trilio-site-recovery-system on each workload cluster. You need cluster-admin or equivalent access to both sets of clusters to install and configure the operator.
• Persistent Volumes and Storage Classes — Site Recovery works at the block level. It provisions DRBD-backed frontend PVCs for each protected VM's disks and requires you to supply storage class mappings between the primary and DR clusters as part of zone configuration. Understanding how PVCs, PVs, and StorageClasses relate is essential for diagnosing replication and protection failures.
• DaemonSets and node taints — The drbd-node-agent DaemonSet runs one pod per worker node on each workload cluster and manages DRBD kernel state on that node. During startup, it applies a siterecovery.trilio.io/not-ready:NoSchedule taint to its node until DRBD converges. You should understand how DaemonSets are scheduled and how node taints interact with workload placement.
• OLM (Operator Lifecycle Manager) — On OpenShift, Site Recovery is installed through OLM using a CatalogSource, OperatorGroup, and Subscription. Familiarity with how OLM manages operator lifecycle and upgrades will help you understand what the operator controls and what it does not.
• KubeVirt — The objects being protected are KubeVirt VirtualMachine resources. You should understand the relationship between a VirtualMachine, its VirtualMachineInstance, and the PVCs that back its disks. Note that live migration and cold migration of protected VMs are denied by admission webhooks for the lifetime of a protection, and draining a node that hosts a running protected VM will not complete.

OpenShift Requirement

Trilio Site Recovery is designed and validated for OpenShift 4.17 and later for the TSR-Manager cluster and both workload clusters. The DRBD node agent relies on the OpenShift privileged Security Context Constraint (SCC), and the TSR web console is accessible only on OpenShift through an oauth-proxy Route created automatically by the ProtectionZone controller. Upstream Kubernetes workload clusters are supported on versions corresponding to OpenShift 4.17 and later, but several capabilities — SCC-based node agent admission, the web console Route, and reliable test-failover network isolation — are OpenShift-specific and are not available or not validated on upstream Kubernetes.

RHEL CoreOS 9 nodes are the validated node distribution for workload clusters in this Tech Preview release. RHEL CoreOS 10 nodes are not validated.

Topology Responsibility

Site Recovery requires you to provision and maintain three separate Kubernetes clusters:

• A TSR-Manager cluster — the dedicated management cluster that hosts all orchestration controllers, stores zone credentials, and holds all TSR-Manager-side custom resources. It runs no VM workloads and carries no DRBD replication traffic.
• A primary (active) workload cluster — where KubeVirt VMs run under normal operating conditions.
• A DR (standby) workload cluster — where standby DRBD replicas are maintained and to which VMs are failed over during a DR event.

Provisioning these clusters, ensuring network connectivity between primary and DR worker nodes on TCP ports 7000–8000 inclusive (one port per replicated VM volume, with port 8000 mandatory), and maintaining round-trip latency below 10 ms between workload clusters for synchronous replication are your responsibility before installing Site Recovery.

Tech Preview Status

This is the initial Tech Preview release of Trilio Site Recovery. All components — including the TSR web console — are Tech Preview. No component has reached general availability. You should factor this into your evaluation and deployment planning.

The following example shows how to verify that your kubectl context is pointed at the correct cluster before running any Site Recovery commands. All TSR-Manager-side resources live in a dr-<name> namespace on the TSR-Manager cluster; running the same command against a workload cluster returns an empty list because those CRDs are not registered there.

# Confirm you are targeting the TSR-Manager cluster
kubectl config current-context

# List all ProtectionZones on the TSR-Manager cluster
kubectl get pz -A

The following example shows how to confirm that workload-side components are installed in the correct namespace on a workload cluster.

# Confirm the workload control plane is running on a workload cluster
kubectl get pods -n trilio-site-recovery-system \
  -l app.kubernetes.io/part-of=site-recovery

# Confirm the DRBD node agent DaemonSet is present
kubectl get daemonset -n trilio-site-recovery-system \
  -l app.kubernetes.io/component=drbd-node-agent

The following example shows how to inspect a ProtectionZone's validation status. The ClustersValidated condition must be True before the TSR-Manager admission webhooks will accept new ProtectionGroup or ProtectionRequest creates.

# Inspect the ClustersValidated condition on a zone named "zone-prod"
# (run against the TSR-Manager cluster, in the dr-zone-prod namespace)
kubectl get pz zone-prod -n dr-zone-prod -o jsonpath='{.status.conditions}' | \
  python3 -m json.tool

• Install and configure the control plane — Covers the OLM-based installation path (CatalogSource, OperatorGroup, Subscription) and the subsequent ProtectionZone CR that triggers automated workload control plane deployment.
• Provision zone credentials — Explains how tsrctl zone-credential create mints the kubeconfig Secrets that grant the TSR-Manager orchestration access to each workload cluster, and how to rotate them.
• Create a ProtectionZone — Describes the top-level configuration object that registers a primary and DR workload cluster pair with the TSR-Manager and validates cluster reachability, identity, and RBAC.
• Protect a virtual machine — Walks through creating a ProtectionRequest to bring a KubeVirt VM under DRBD replication and reach the Protected phase.
• Monitor replication health — Explains ReplicationGroupStatus and RPOEvent custom resources, and how to use them to assess replication health and SLA compliance.
• Run a test failover — Covers TestFailover CRs and the isolated test namespace created on the standby cluster for non-disruptive DR validation.
• Execute a planned failover — Describes creating a FailoverRequest with failoverType: planned to perform a graceful, zero-data-loss role flip.
• Execute an unplanned failover — Describes creating a FailoverRequest with failoverType: unplanned for RTO-optimized forced promotion when the primary site is unavailable.
• Collect a support bundle — Explains how to run oc adm must-gather with the site-recovery-must-gather image on the TSR-Manager cluster to collect logs, CRs, and DRBD state from the entire estate.