Intended Audience

This page describes who Trilio Site Recovery is built for, what Kubernetes and disaster recovery knowledge you need before you begin, and which roles in a platform or SRE organization are most likely to interact with it. Understanding the intended audience helps you decide whether to read the full operator documentation or to focus on specific workflows relevant to your role.

Who This Operator Is For

Trilio Site Recovery is designed for platform engineers and site reliability engineers (SREs) who are responsible for running VM workloads on OpenShift and must meet enterprise disaster recovery requirements. If you own the DR runbook, are on call when a cluster goes down, or are responsible for demonstrating recovery time and recovery point objectives to compliance teams, this operator is your primary tool.

The operator is not aimed at application developers. Application teams do not need to modify their workloads, change their VM definitions, or adopt a new SDK. All protection, replication, failover, and recovery operations are driven through Kubernetes Custom Resource Definitions and are transparent to the applications running inside the VMs.

Required Knowledge

Kubernetes and OpenShift

You should be comfortable with the following before working with Trilio Site Recovery:

• Kubernetes core concepts: Pods, Deployments, DaemonSets, Namespaces, PersistentVolumeClaims, and StorageClasses. The operator introduces eight CRD kinds on the quorum cluster and one on each workload cluster; reading and interpreting their status fields requires familiarity with the Kubernetes object model.
• Custom Resource Definitions (CRDs): You will apply, watch, and interpret CRs using kubectl and oc. Understanding kubectl get, kubectl describe, kubectl apply, and kubectl delete is required. The operator uses the siterecovery.trilio.io/v1alpha1 API group.
• OpenShift-specific tooling: oc is required for several workflows, including collecting diagnostic bundles with oc adm must-gather and interacting with OpenShift Routes. Kubectl-only operation is not a supported mode.
• OLM (Operator Lifecycle Manager): Installation of the operator bundle is done through OLM via a CatalogSource, OperatorGroup, and Subscription. You should know how to create these resources and how to verify that an operator has been successfully installed.
• Multi-cluster kubeconfig management: The operator manages three clusters — a quorum cluster, a primary workload cluster, and a DR workload cluster. You must be able to supply and manage kubeconfig files for all three, and you must be comfortable issuing kubectl and oc commands with explicit --kubeconfig or --context flags to target the correct cluster.

Storage and Replication

You do not need to be a DRBD expert, but you should understand the following:

• Block storage replication: Trilio Site Recovery replicates VM-attached PersistentVolumeClaims at the block layer using DRBD. A general understanding of what block-level replication means — and how it differs from file-level backup — will help you interpret replication status and diagnose issues.
• Synchronous replication constraints: The operator uses DRBD Protocol C exclusively, which guarantees RPO=0 by acknowledging writes only after they are committed on both the primary and DR clusters. This requires sub-50ms round-trip latency between primary and DR worker nodes. If your network does not meet this requirement, the product is not suitable for your environment.
• LVM thin pools: Each worker node on the primary and DR clusters must have an LVM thin pool configured on a dedicated block device. This is the backing storage for DRBD. You should know how to verify that a thin pool exists and is correctly sized.
• TCP port planning: DRBD replication uses one TCP port per replicated VM volume, drawn from the range 7000–8000 inclusive. You will need to work with your network team to open this range between primary and DR worker nodes before protecting any VMs.

Virtualization

You should be familiar with KubeVirt or OpenShift Virtualization (CNV) at an operational level: how VMs are defined as VirtualMachine CRs, how PVCs are attached as disks, and how VM lifecycle states (running, stopped, migrating) are reflected in the API. You do not need deep KubeVirt internals knowledge, but you must understand that a protected VM is pinned to one node per cluster for the lifetime of its protection — live migration and cold migration of a protected VM are denied by admission webhook, and draining a node that hosts a running protected VM will not complete.

Roles and Responsibilities

Platform Engineer

Platform engineers are typically responsible for the initial deployment and ongoing maintenance of the operator. Your tasks will include:

• Installing the OLM bundle on the quorum cluster
• Creating kubeconfig Secrets and the ProtectionZone CR that bootstraps the entire control plane
• Verifying that the site-recovery-quorum-control-plane and site-recovery-workload-control-plane components are healthy after the ProtectionZone controller deploys them automatically
• Managing upgrades to Site Recovery components
• Adding new DR deployments for additional tenants

SRE / DR Operator

SREs and DR operators interact with the operator day-to-day and are the primary users during an actual disaster. Your tasks will include:

• Creating and monitoring ProtectionRequest CRs to protect VMs
• Watching ProtectionGroup and ReplicationGroupStatus CRs to verify replication health
• Running TestFailover CRs on a regular schedule to validate recoverability without impacting production
• Executing planned failovers via FailoverRequest during maintenance windows
• Executing unplanned failovers when the primary cluster is unavailable
• Collecting diagnostic bundles with oc adm must-gather and interpreting them when replication degrades

Application Team (Limited Involvement)

Application teams do not need to interact with this operator directly. If an application team requests DR protection for their VM workloads, a platform engineer or SRE creates the ProtectionRequest CR on their behalf. Application teams should be aware that protected VMs cannot be live-migrated and that their VMs will be switched to DRBD-backed frontend PVCs as part of the protection workflow — but no changes to the application inside the VM are required.

What This Operator Is Not

• Not a backup tool: Trilio Site Recovery is not a replacement for snapshot-based backup. It provides synchronous block replication for continuous protection, not point-in-time recovery across a retention window.
• Not a multi-cloud replication engine: The operator is designed for two workload clusters (primary and DR) managed through a single quorum cluster. It is not designed to replicate data to object storage or across more than two workload clusters per protection zone.
• Not a general-purpose volume replication tool: DRBD is the only supported storage backend. Other storage backends, including LINSTOR-only configurations, are not supported in the current release.
• Not supported on upstream Kubernetes for the quorum cluster: The operator bundle targets OpenShift 4.17 and later for the quorum cluster and for both workload clusters. The quorum cluster must run OpenShift. The TSR web console, DRBD node agent SCC requirements, and test-failover network isolation all depend on OpenShift capabilities.

The following examples illustrate the kinds of kubectl and oc commands you will use regularly. These are representative of the day-to-day operator workflow — not install steps — and assume the operator is already deployed.

Check the status of all Protection Zones on the quorum cluster

Protection Zones live in dr-<name> namespaces on the quorum cluster. Use the pz short name to list them:

oc --kubeconfig $KUBECONFIG_QUORUM get pz -A

Expected output:

NAMESPACE    NAME          DISPLAY NAME   BACKEND   CLUSTERS               STATUS      AGE
dr-prod      prod-zone     Production     DRBD      cluster1, cluster2     Available   12d
dr-staging   staging-zone  Staging        DRBD      cluster1, cluster2     Available   3d

The STATUS column reflects status.phase. A zone in Available phase means the quorum control plane and both workload control planes are healthy and ready to protect VMs.

Check the replication health of a Protection Group

The ReplicationGroupStatus CR (short name: rgs) is auto-created by the replication monitor in the zone namespace on the quorum cluster. One rgs object exists per Protection Group, named <protection-group-name>-replication:

oc --kubeconfig $KUBECONFIG_QUORUM get rgs -n dr-prod

Expected output:

NAME                   PROTECTION-GROUP   RPO-STATUS   OUT-OF-SYNC   SYNCED   CONNECTION   LAST-SYNC              AGE
webapp-pg-replication  webapp-pg          Met          0             4        Connected    2024-01-15T10:23:00Z   5d

An OUT-OF-SYNC value of 0 with CONNECTION of Connected and RPO-STATUS of Met confirms that all volumes are fully synchronised and the protection group is ready for failover with RPO=0.

List all protected VMs on a workload cluster

The siterecovery.trilio.io/protected-vm=true label is stamped on VirtualMachine objects on the workload clusters — not on any Site Recovery CR. Query it on the primary cluster:

kubectl --kubeconfig $KUBECONFIG_CLUSTER1 get vm -A \
  -l siterecovery.trilio.io/protected-vm=true

Expected output:

NAMESPACE   NAME          AGE   STATUS    READY
app-ns      vm-web-01     5d    Running   True
app-ns      vm-db-01      5d    Running   True

Collect a diagnostic bundle for a degraded zone

Run oc adm must-gather on the quorum cluster. The tsr-gather tool inside the image collects logs and CRD state from all clusters in the DR estate automatically:

oc adm must-gather \
  --image=quay.io/triliovault/site-recovery-must-gather:<tag> \
  -- /usr/bin/gather --zone prod-zone --since 2h

The bundle is written to a timestamped directory in the current working directory. Read SUMMARY.md first for a summary of detected issues, then manifest.yaml for the full inventory of what was collected.

• Architecture overview — Explains how the quorum cluster, primary cluster, and DR cluster relate to each other, and how the ProtectionZone controller bootstraps the full control plane from a single CR.
• Plan and verify infrastructure — Covers the network, storage, and cluster prerequisites you must satisfy before installing the operator, including LVM thin pool configuration, TCP port ranges, and latency requirements for Protocol C replication.
• Deploy the workload control plane — Describes how the ProtectionZone controller automatically deploys the DRBD node agent DaemonSet and supporting RBAC to your primary and DR clusters once the zone reaches Available.
• Protect virtual machines — The primary day-2 workflow for SREs: how to create a ProtectionRequest, what the protection phases mean, and how to verify that a VM is fully synchronised before running a test failover.
• Verify replication health — Explains how to interpret ReplicationGroupStatus, RPOEvent, and DRBDResource status fields, and how to use label selectors to filter replication objects correctly.
• Run a test failover — Describes the TestFailover CR lifecycle, how the controller selects the target cluster, and how to inspect results in status.testNamespace without disrupting production workloads.
• Diagnose a degraded or failed node or replication link — Runbook-style guidance for SREs responding to Degraded or Critical replication status, node taints applied by the DRBD node agent, and how to collect and interpret diagnostic bundles.