Intended Audience

This page describes who Trilio Site Recovery is designed for, what background knowledge you need to use it effectively, and what operational roles benefit most from it. Understanding whether this product fits your team and environment before you begin installation saves time and helps you set realistic expectations about the workflows and responsibilities involved.

Who this product is for

Trilio Site Recovery is built for platform engineers and site reliability engineers (SREs) who operate Kubernetes infrastructure with disaster recovery requirements for virtual machine workloads. If you are responsible for defining recovery objectives, maintaining cluster availability across geographic regions, and ensuring that VM workloads can survive a site failure, this product is aimed at you.

The product is not a general-purpose backup tool, and it is not intended for application developers who want a self-service DR experience. All operations—protecting VMs, monitoring replication health, running test failovers, and triggering failovers—are driven by Kubernetes Custom Resource Definitions and require cluster-level access to at minimum two OpenShift workload clusters and a dedicated TSR-Manager cluster.

Required Kubernetes knowledge

Trilio Site Recovery assumes an intermediate level of Kubernetes and OpenShift familiarity. Specifically, you should be comfortable with:

• Custom Resource Definitions and the Kubernetes API. Every DR operation is expressed as a CR (ProtectionGroup, ProtectionRequest, FailoverRequest, TestFailover, and so on) in the siterecovery.trilio.io/v1alpha1 API group. You will spend most of your time creating, watching, and interpreting these objects with kubectl or oc.
• Namespaces and RBAC. TSR-Manager components and all TSR-Manager-side CRs live in a dr-<name> namespace. Workload components live in trilio-site-recovery-system on each workload cluster. Confusing these namespaces is the most common source of empty kubectl get results.
• OLM and Operator lifecycle. Installation on the TSR-Manager cluster is performed through Operator Lifecycle Manager using a CatalogSource, OperatorGroup, and Subscription. You should know how to create these objects and how to check the status of an installed operator.
• Kubeconfig management. You need valid kubeconfig files for all three clusters—TSR-Manager, primary, and DR—and you must be able to pass them correctly to kubectl and oc commands (using --kubeconfig or --context).
• Storage concepts. The product uses DRBD block replication backed by LVM thin pools. You should understand PersistentVolumes, PersistentVolumeClaims, StorageClasses, and VolumeSnapshots at a working level. You do not need to be a DRBD expert—the operator manages DRBD configuration—but you do need to understand that replication happens at the block layer and that VM disks are migrated to DRBD-backed PVCs during protection.
• KubeVirt or OpenShift Virtualization. Your VM workloads must already be running as KubeVirt VirtualMachine objects. Trilio Site Recovery protects VMs at the storage layer without requiring application changes, but you need to understand how KubeVirt manages VM lifecycle, especially that a protected VM is pinned to a specific node for the lifetime of its protection.

What operational knowledge is assumed

Beyond Kubernetes, you should understand:

• Disaster recovery fundamentals. You should know what RPO (Recovery Point Objective) and RTO (Recovery Time Objective) mean and how your organization's requirements translate into infrastructure choices. Trilio Site Recovery enforces RPO=0 through synchronous Protocol C DRBD replication, which requires sub-50ms round-trip latency between primary and DR clusters. If your site-to-site latency exceeds this threshold, the product cannot meet its replication guarantees.
• Network and firewall administration. DRBD replication requires TCP ports 7000–8000 inclusive to be open between worker nodes of the primary and DR clusters—one port per replicated VM. Port 8000 is part of the required range; a firewall rule that stops at 7999 will silently prevent replication on one volume. The Kubernetes API port (TCP 6443) must also be reachable from the TSR-Manager cluster to the API servers of both workload clusters.
• Linux storage administration. Each worker node on the primary and DR clusters requires an LVM thin pool backed by a dedicated block device. The DRBD kernel module (version 9.x or later) must be present on those nodes.

What you do not need to know

You do not need to:

• Understand DRBD configuration files or DRBD CLI tools. The drbd-node-agent DaemonSet manages DRBD at the kernel level on your behalf.
• Run Helm commands directly. The control plane charts are embedded in the operator binary and are deployed automatically by the ProtectionZone controller once a zone reaches Available. You will never run helm install or helm upgrade as part of normal operations.
• Write or modify DRBDReplicationPolicy resources. The ProtectionZone controller creates a default policy named <zoneName>-default with isDefault: true automatically. Replication is always synchronous Protocol C; there is no protocol selection to make.

Platform scope

Trilio Site Recovery is supported on OpenShift 4.17 and later for the TSR-Manager cluster and both workload clusters. Single-Node OpenShift is supported for workload and TSR-Manager clusters. The web console (TSR web console) requires OpenShift—it is accessible via an oauth-proxy Route created by the ProtectionZone controller. If you are evaluating the product, plan for an OpenShift environment across all three clusters.

This is a Tech Preview release. No component is separately GA. All functionality described in this documentation reflects the current Tech Preview release; there is no prior released version.

Multi-tenant and multi-cluster responsibilities

A single TSR-Manager cluster can host multiple protection zones, each in its own dr-<name> namespace, managing separate pairs of workload clusters. If your organization has multiple DR deployments to manage—for different teams, environments, or regulatory boundaries—you operate each zone independently using its own namespace and its own set of CRs. Understanding namespace boundaries and which cluster each CR lives on is essential before you begin.

The following examples illustrate the kinds of kubectl and oc commands you will use regularly. They are not installation steps—they show the operational vocabulary you should be familiar with before using this product.

Check which CRs exist on the TSR-Manager cluster

# Run against your TSR-Manager cluster kubeconfig
kubectl --kubeconfig ~/.kube/config-tsr-manager \
  get protectionzones,protectiongroups,protectionrequests,failoverrequests,testfailovers \
  -A

Check which CRs exist on a workload cluster

# DRBDResource lives on the workload cluster, not the TSR-Manager cluster
kubectl --kubeconfig ~/.kube/config-primary \
  get dres -A

Watch a ProtectionRequest progress through its phases

# Phases: Pending → Validating → CreatingDRBD → Syncing → ReadyToActivate → Activating → Protected
kubectl --kubeconfig ~/.kube/config-tsr-manager \
  get pr -n dr-production -w

Watch a FailoverRequest progress

# State column: Pending → InProgress → Completed
kubectl --kubeconfig ~/.kube/config-tsr-manager \
  get fr -n dr-production -w

Collect a diagnostic bundle from the whole DR estate

# Run on the TSR-Manager cluster; the gather tool collects from all clusters
oc adm must-gather --image=quay.io/triliovault/site-recovery-must-gather:<release-tag>

• Architecture overview — How the TSR-Manager cluster, primary cluster, and DR cluster relate to each other and which components run where.
• Prerequisites — The full list of cluster, network, storage, and software requirements before installation.
• Plan and verify infrastructure — The first workflow step: confirming that your clusters, network paths, and storage are ready before you deploy.
• Deploy the workload control plane — How the ProtectionZone controller automatically installs the workload components on your primary and DR clusters.
• Protect virtual machines — How to create a ProtectionRequest and what the protection lifecycle phases mean.
• Verify replication health — How to read ReplicationGroupStatus and RPOEvent objects to confirm that DRBD synchronization is operating correctly.
• TSR web console — How the browser-based management interface works on OpenShift and what operations it supports.