Intended Audience

This page describes who Trilio Site Recovery is designed for, what Kubernetes and OpenShift experience you need to use it effectively, and where it fits within a broader platform engineering or site reliability practice. Understanding the intended audience helps you decide whether this product matches your operational context and what background reading to prioritize before you begin.

Who this product is for

Trilio Site Recovery is built for platform engineers and site reliability engineers (SREs) who are responsible for designing, operating, and maintaining disaster recovery capabilities for VM workloads running on OpenShift clusters. It is not a general-purpose backup tool and is not aimed at application developers or cluster administrators who manage only a single cluster.

You are the right audience for this product if you:

• Own or co-own the DR strategy for one or more OpenShift environments running KubeVirt or OpenShift Virtualization (CNV) virtual machines
• Are responsible for meeting Recovery Point Objective (RPO) and Recovery Time Objective (RTO) commitments with your organization or your customers
• Manage infrastructure across at least two geographically separated OpenShift clusters
• Are comfortable applying Kubernetes Custom Resource manifests with kubectl or oc and operating Helm-deployed workloads
• Need to integrate DR workflows into GitOps pipelines or automate them through CI/CD tooling

What Kubernetes knowledge is required

Trilio Site Recovery follows the Kubernetes operator pattern throughout. All DR operations—protecting VMs, triggering failover, running test failovers, and monitoring replication health—are expressed as Custom Resource Definitions (CRDs) that you create and manage with kubectl or oc. You do not call internal APIs directly, and there is no proprietary CLI that replaces standard Kubernetes tooling.

Before deploying or operating this product, you should be comfortable with the following Kubernetes concepts:

Required knowledge:

• Creating, patching, and watching Kubernetes custom resources with kubectl apply, kubectl get, and kubectl describe
• Reading and interpreting Kubernetes resource status fields and conditions
• Working with Helm 3: installing charts, overriding values, and managing releases across namespaces
• Managing multi-cluster access with kubeconfig files and context switching
• Understanding PersistentVolumeClaims, StorageClasses, and how block-level storage is attached to pods and VMs
• Reading controller logs and understanding the reconciliation loop model
• Applying RBAC manifests (ClusterRole, ClusterRoleBinding) and understanding why cross-namespace and cross-cluster permissions are necessary in DR scenarios

Helpful but not required on day one:

• Familiarity with KubeVirt or OpenShift Virtualization VM lifecycle management (VirtualMachine and VirtualMachineInstance resources)
• Experience with DRBD or block-level storage replication concepts
• GitOps workflow tooling (Argo CD, Flux) for managing CRD-based DR configurations declaratively
• The oc adm must-gather diagnostic pattern, which is used by the tsr-gather support bundle tool

OpenShift requirement

Trilio Site Recovery currently supports OpenShift 4.14 and later only. Plain Kubernetes clusters are not a supported deployment target in this release. All installation steps, CLI examples, and operational procedures in this documentation assume an OpenShift environment with oc available alongside kubectl.

Operational context

The product is designed for teams operating at an intermediate to advanced level of Kubernetes maturity. If your team is still building foundational OpenShift skills, we recommend establishing experience with KubeVirt VM lifecycle management and multi-cluster Helm deployments before introducing Site Recovery into your environment. DR failover operations are stateful and time-sensitive; operating them effectively requires confidence with cross-cluster kubectl commands and the ability to interpret CRD status fields quickly under pressure.

If you are evaluating Site Recovery as part of a broader DR design exercise, the architecture overview and deployment model pages provide the conceptual grounding you need before working through any operational workflow.

The following example illustrates the kind of interaction pattern you will use throughout this product. All DR operations—including protecting a VM, monitoring replication, and triggering failover—follow the same kubectl / oc apply-and-watch pattern shown here.

Verify you can reach all clusters and query Site Recovery CRDs

# Confirm access to the quorum cluster and list ProtectionZone resources
oc --kubeconfig $KUBECONFIG_QUORUM get protectionzone -A

# Confirm access to the primary cluster and list ProtectionRequests
oc --kubeconfig $KUBECONFIG_CLUSTER1 get protectionrequest -A

# Confirm access to the DR cluster
oc --kubeconfig $KUBECONFIG_CLUSTER2 get protectionrequest -A

Expected output on a freshly installed system (no deployments yet):

# Quorum cluster
No resources found.

# Primary cluster
No resources found.

# DR cluster
No resources found.

If any of these commands return an authentication error or a no matches for kind error, your kubeconfig access or CRD installation is incomplete. Resolve those issues before proceeding to any workflow in this documentation.

Check that the quorum control plane is running

oc --kubeconfig $KUBECONFIG_QUORUM get pods -n dr-<deployment-name>

Expected output (controller manager pod in Running state):

NAME                                              READY   STATUS    RESTARTS   AGE
site-recovery-quorum-control-plane-<hash>         2/2     Running   0          5m

This pod packages the failover, protection, pg-sync, and replication-monitor reconcilers. A CrashLoopBackOff or non-ready state here blocks all DR operations and should be diagnosed before proceeding.

• Architecture overview — Describes the three-cluster topology, the role of the quorum cluster, and how the DRBD Operator deployment model is structured
• Deployment model — Explains the difference between a two-cluster and three-cluster configuration and when each applies
• Plan and verify infrastructure — The first operational workflow; covers network requirements, OpenShift version prerequisites, and kubeconfig setup before any Helm chart is installed
• Key concepts: ProtectionRequest, FailoverRequest, TestFailover — Explains the CRDs that drive day-to-day DR operations and the lifecycle phases each one passes through
• Diagnose a degraded or failed node or replication link — Troubleshooting reference for SREs responding to replication alerts or failover failures under time pressure
• tsr-gather support bundle — How to collect a diagnostic bundle across the full DR estate using oc adm must-gather for escalation or self-service troubleshooting