Intended Audience

This page describes who Site Recovery is designed for, what background knowledge you need to use it effectively, and where you might need to deepen your skills before working with the platform. Understanding the intended audience helps you decide whether Site Recovery fits your role and how to approach the learning curve for its core concepts.

Who should use Site Recovery

Site Recovery is built for platform engineers and site reliability engineers (SREs) who are responsible for the availability and resilience of Kubernetes clusters and the virtualized workloads running on them. You are the right audience if you own or co-own any of the following responsibilities:

• Designing and operating disaster recovery (DR) strategies for Kubernetes-hosted virtual machines
• Managing KubeVirt or OpenShift Virtualization environments in production
• Maintaining high-availability clusters across geographically distributed sites
• Defining and meeting recovery point (RPO) and recovery time (RTO) objectives for business-critical workloads
• Operating storage infrastructure, including block storage replication, at the platform level

Site Recovery is not designed for application developers who want to make individual applications resilient. It operates at the infrastructure layer, protecting virtual machines and their underlying storage volumes without requiring application changes. Application owners benefit from the protection it provides, but they do not interact with it directly.

Required Kubernetes knowledge

Site Recovery is a Kubernetes operator that exposes its entire configuration and operational surface through Custom Resource Definitions (CRDs). To use it effectively, you need a solid working knowledge of Kubernetes at an intermediate level. Specifically, you should be comfortable with the following:

Core Kubernetes concepts

• Creating, inspecting, and editing resources using kubectl apply, kubectl get, kubectl describe, and kubectl edit
• Understanding how controllers and the operator pattern work: controllers watch resources and continuously reconcile desired state with actual cluster state
• Working with namespaces, RBAC, and kubeconfig files across multiple clusters
• Reading and authoring YAML manifests for Kubernetes resources

Custom Resources and operators

• Knowing what a CRD is and how custom resources extend the Kubernetes API
• Understanding how to interact with operator-managed resources and interpret their .status fields
• Recognizing reconciliation loops and how operators react to resource changes

Multi-cluster operations

• Managing kubeconfig contexts for more than one cluster simultaneously
• Understanding the difference between a management cluster (the quorum cluster in Site Recovery) and workload clusters (primary and DR clusters)

You do not need to be a Kubernetes core contributor or have experience building operators, but you should be past the beginner stage of only running pre-packaged Helm charts.

Required disaster recovery knowledge

Site Recovery automates complex DR workflows, but you need foundational DR concepts to configure it correctly and operate it under pressure. Before deploying Site Recovery in a production environment, you should understand:

Core DR concepts

• RPO (Recovery Point Objective): The maximum acceptable amount of data loss measured in time. Site Recovery achieves RPO=0 with synchronous DRBD replication (Protocol C) and near-zero RPO with asynchronous replication (Protocol A).
• RTO (Recovery Time Objective): The maximum acceptable duration of downtime. Site Recovery targets 3–8 minutes for automated failover.
• Planned failover: A graceful, coordinated failover where VMs are shut down on the primary cluster before DR volumes are promoted — ensuring zero data loss.
• Unplanned failover: An emergency failover triggered when the primary cluster is unavailable, where DR volumes are promoted without a graceful shutdown.
• Failback: The process of returning VMs and replication to the original primary cluster after it has been restored.
• Split-brain: A failure condition where both primary and DR DRBD volumes simultaneously hold the primary role, resulting in divergent data that requires manual resolution. Understanding this risk is essential for operating DRBD-based replication.

Replication fundamentals

• What block-level storage replication means and how it differs from application-level or file-level replication
• The trade-off between synchronous replication (Protocol C, RPO=0, requires low-latency links under 10ms RTT) and asynchronous replication (Protocol A, small RPO window, tolerates higher latency)
• How LVM thin-provisioned storage pools underpin DRBD volume management

DR testing

• Why non-disruptive DR tests (test failovers) are essential and what they validate
• The concept of using volume snapshots to create isolated test environments without affecting production

Required storage knowledge

Because Site Recovery replicates block storage volumes at the kernel level using DRBD, you need a working understanding of storage concepts:

• PersistentVolumes and PersistentVolumeClaims: How Kubernetes abstracts storage and how VMs attach to storage through PVCs
• Storage classes: How storage classes map provisioners and parameters, and why storage class mappings between clusters matter for DR
• DRBD basics: What the DRBD kernel module does, that it operates at the block device layer, and that it requires version 9.0 or later on worker nodes
• LVM thin provisioning: That Site Recovery requires LVM thin-provisioned storage pools on worker nodes
• CSI snapshots: That the VolumeSnapshot capability (provided by a CSI snapshotter) is required on both clusters when using test failover (supported in the DRBD Operator deployment model)

Deep DRBD expertise is not required before getting started — the DRBD Operator manages DRBD resource lifecycle on your behalf — but you should understand what DRBD replication is and recognize its operational failure modes, such as split-brain.

Required virtualization knowledge

Site Recovery protects virtual machines running on KubeVirt or OpenShift Virtualization. You should be comfortable with:

• Creating and managing VirtualMachine resources in KubeVirt or OpenShift Virtualization
• Understanding how VMs attach to storage through PVCs and DataVolumes
• Recognizing that Site Recovery switches a VM's PVCs to DRBD-backed frontend PVCs after protection is established — the VM continues operating on the same interface, but disk I/O is now routed through the replication layer

Deployment model awareness

Site Recovery supports two deployment models that differ in topology, component placement, and the CRDs you use:

You need to understand which model your infrastructure uses before configuring protection policies, because the CRDs, controllers, and operational procedures differ between them. The pages linked below provide further context for each model.

Skills you can develop as you go

You do not need to master every area before starting. The following skills are useful but learnable through the documentation and hands-on practice:

• Writing ProtectionGroup, ProtectionRequest, FailoverRequest, TestFailover, and DRBDReplicationPolicy manifests
• Using pgctl for deployment context management and operational tasks
• Using quorum-deployments.sh for menu-driven operational workflows
• Interpreting ReplicationGroupStatus and RPOEvent resources to assess replication health
• Navigating the Site Manager UI for dashboards, Protection Group management, and failover monitoring

The following example illustrates the kind of resource interaction a platform engineer or SRE performs with Site Recovery. It is not a complete workflow — it demonstrates the interaction model you need to be comfortable with.

Inspecting the status of a Protection Group on the primary cluster

After protection is established, you inspect the Protection Group's replication state to confirm it is Consistent before scheduling a maintenance window:

kubectl --kubeconfig $KUBECONFIG_CLUSTER1 get protectiongroup my-app-pg -o yaml

Expected output (abbreviated):

apiVersion: siterecovery.trilio.io/v1alpha1
kind: ProtectionGroup
metadata:
  name: my-app-pg
  namespace: default
status:
  replicationState: Consistent
  virtualMachines:
    - name: vm-web-server
      syncState: Synced
    - name: vm-database
      syncState: Synced

This output tells you that both VMs in the group are fully synchronized and the group is ready for a planned failover or a test failover.

Checking for RPO violations on the quorum cluster

If replication lag has exceeded your configured threshold, the replication-monitor agent creates an RPOEvent resource. You check for recent violations as part of your daily SRE review:

kubectl --kubeconfig $KUBECONFIG_QUORUM get rpoevents -A

Expected output (abbreviated):

NAMESPACE   NAME                        PROTECTION-GROUP   LAG      SEVERITY   AGE
dr-prod     rpo-my-app-pg-1714000000    my-app-pg          18s      Warning    5m

This tells you which Protection Group was affected, the observed lag at the time of the event, and its severity — giving you the information needed to investigate a replication bottleneck or network issue before it becomes a data-loss risk.

• Architecture overview — How the quorum cluster, primary cluster, and DR cluster relate to each other, and where each controller runs
• Deployment models — Detailed comparison of the DRBD Operator model and the centralized storage model, including topology diagrams and component placement
• ProtectionGroup — The CRD used to group VMs for coordinated failover in centralized storage deployments
• ProtectionRequest — The CRD used to protect individual VMs in DRBD Operator deployments
• FailoverRequest — How to trigger planned and unplanned failovers and monitor their progress
• TestFailover — How to validate DR readiness non-disruptively using volume snapshots (DRBD Operator model)
• ReplicationGroupStatus and RPOEvent — How to interpret aggregated replication health and audit lag violations
• DRBDReplicationPolicy — How to configure cross-cluster replication settings including protocol selection and storage class mappings
• pgctl reference — Command-line reference for deployment context management and operational tasks
• Site Manager UI — Web-based dashboard for cluster health, Protection Group management, and failover monitoring