Custom Resource Schemas

This page documents the complete schema for every Custom Resource Definition (CRD) in the siterecovery.trilio.io/v1alpha1 API group. These CRDs are the primary interface for all Trilio Site Recovery operations — protecting VMs, triggering failovers, monitoring replication health, and running DR validation tests are all driven by creating and observing these resources. Understanding the field shapes, enum values, validation rules, and status conditions for each CRD is essential for building automation, writing GitOps manifests, and diagnosing operational issues.

Before working with these resources, you need:

• An OpenShift 4.17 or later cluster designated as the TSR-Manager cluster, with the Trilio Site Recovery operator installed via OLM
• Two OpenShift 4.17 or later workload clusters, each with the site-recovery-workload-control-plane stack deployed (this happens automatically once your ProtectionZone reaches Available)
• A ProtectionZone CR in an Available phase — the TSR-Manager-side CRDs (ProtectionGroup, ProtectionRequest, FailoverRequest, TestFailover, ReplicationGroupStatus, RPOEvent, DRBDReplicationPolicy) are only usable after the zone is available
• The oc CLI configured with access to the TSR-Manager cluster; oc is required for OpenShift-specific operations
• Familiarity with the cluster topology: the TSR-Manager cluster hosts all zone-scoped CRs in a dr-<name> namespace; the workload clusters host DRBDResource CRs in the protected VM's namespace under the trilio-site-recovery-system workload stack

API group and version: All CRDs are in the siterecovery.trilio.io group, version v1alpha1. All resources are Namespaced in scope.

The CRDs are installed automatically — you do not apply CRD manifests by hand.

TSR-Manager-side CRDs (ProtectionZone, ProtectionGroup, ProtectionRequest, FailoverRequest, TestFailover, ReplicationGroupStatus, RPOEvent, DRBDReplicationPolicy) are installed by the OLM operator bundle and by the embedded control-plane Helm charts. The bundle installs ProtectionZone; the site-recovery-manager-control-plane chart installs the remaining seven once the ProtectionZone controller deploys it.

Workload-side CRDs (DRBDResource) are installed by the site-recovery-workload-control-plane chart on each workload cluster.

You can verify CRD registration after the operator is installed and a ProtectionZone is Available:

# On the TSR-Manager cluster
oc get crd | grep siterecovery.trilio.io

You should see all eight TSR-Manager-side CRDs:

drbdreplicationpolicies.siterecovery.trilio.io
failoverrequests.siterecovery.trilio.io
hooks.siterecovery.trilio.io
protectiongroups.siterecovery.trilio.io
protectionrequests.siterecovery.trilio.io
protectionzones.siterecovery.trilio.io
replicationgroupstatuses.siterecovery.trilio.io
rpoevents.siterecovery.trilio.io
testfailovers.siterecovery.trilio.io

# On each workload cluster
oc get crd drbdresources.siterecovery.trilio.io

Important: Running oc get drbdresource against the TSR-Manager cluster returns server doesn't have a resource type — DRBDResource is registered only on the workload clusters, never on the TSR-Manager cluster.

This section describes each CRD's spec fields, validation rules, and status shape. Fields marked (required) must be present; all others are optional and carry the defaults shown.

ProtectionZone

Short name: pz | Namespace: dr-<name> on TSR-Manager | Cluster: TSR-Manager only

A ProtectionZone is the top-level object that groups the two workload clusters into a DR deployment. Creating one triggers the protection-zone-controller to deploy the manager and workload control-plane stacks. Every other zone-scoped resource lives in the same dr-<name> namespace.

spec fields

status fields

kubectl get columns: Display Name, Backend, Clusters, Status, Age

ProtectionGroup

Short name: pg | Namespace: dr-<name> on TSR-Manager

A ProtectionGroup is a logical bundle of KubeVirt VMs that fail over together as one atomic unit. You create one per set of VMs that must maintain consistency across a failover.

spec fields

status fields

kubectl get columns: VMs, State, Active, Age

ProtectionRequest

Short name: pr, protect | Namespace: dr-<name> on TSR-Manager

A ProtectionRequest requests block-level DRBD replication protection for a single KubeVirt VM. One ProtectionRequest is created per VM. The protection-controller validates the VM, provisions the DRBDResource pair (one per workload cluster), runs initial synchronization, and switches the VM to DRBD-backed storage.

Important operational constraints:

• The VM must be running when you create the ProtectionRequest.
• Once protected, the VM is pinned to one node per cluster for the lifetime of the protection. nodeName is immutable once set. Live migration and cold migration of a protected VM are denied.
• Re-protection always requires a full unprotect followed by a full initial resynchronization.

spec fields

status phases

The status.phase field progresses through these exact values:

key status fields

kubectl get columns: VM, Namespace, Phase, Sync, Age

FailoverRequest

Short name: fr | Namespace: dr-<name> on TSR-Manager

A FailoverRequest initiates a planned or unplanned failover of a ProtectionGroup from its active cluster to a target cluster. Every failover — including failback — is initiated by creating this resource. The failover-controller watches FailoverRequest CRs and orchestrates the operation.

Spec is immutable. All fields are fixed at creation time. To retry a failed failover, delete the FailoverRequest and create a new one.

spec fields

Note on drainTimeoutSeconds: This field is accepted and range-checked by the admission webhook (30–3600, default 300) but is not consumed by the failover controller in Tech Preview. It has no effect on drain or failover behavior and should not be relied upon.

status fields

kubectl get columns: Protection Group, Target, State, Phase, Age

TestFailover

Short name: tfo | Namespace: dr-<name> on TSR-Manager

A TestFailover triggers a non-disruptive DR validation. The test-failover-controller creates volume snapshots, provisions test PVCs and VMs in an isolated namespace on the target cluster, runs verification checks, and cleans up. Production VMs and replication are not interrupted.

Test namespace: The controller generates the test namespace as site-recovery-<protection-group>-<random> and records it in status.testNamespace. You do not choose or construct this name.

spec fields

status phases

The status.phase field progresses through these exact values:

key status fields

kubectl get columns: Protection Group, Phase, Result, Passed, Scheduling, Age

DRBDReplicationPolicy

Short name: drp, drbdpolicy | Namespace: dr-<name> on TSR-Manager

A DRBDReplicationPolicy defines how volumes replicate between the two workload clusters. You do not create or modify this resource. The ProtectionZone controller creates exactly one default policy named <zoneName>-default with isDefault: true in the zone's namespace when the zone becomes Available. Only the isDefault policy in the ProtectionRequest's namespace is ever consulted.

This schema is documented here for reference when reading oc get drp output or diagnosing replication configuration.

spec fields (read-only reference)

Note on networkConfig.portRange: This field is accepted by the schema but is never read by the port allocator. DRBD replication ports are always allocated from the fixed range TCP 7000–8000 inclusive (one port per replicated VM), regardless of what portRange says. Port 8000 is allocatable; a firewall rule stopping at 7999 will silently prevent replication on one volume.

kubectl get columns: Clusters, Mode, Protocol, Default, Phase, Age

DRBDResource

Short name: dres | Namespace: VM's namespace on workload clusters only

A DRBDResource represents all the replicated disks of a single VM as one DRBD resource. One CR exists per cluster side (source and target) in the VM's namespace on each workload cluster. The naming pattern is drbd-<namespace>-<vm>-<hash8>. This resource is created and managed by the protection-controller; you do not author it.

Cluster placement: DRBDResource CRs exist only on workload clusters. Running oc get dres against the TSR-Manager cluster returns server doesn't have a resource type. The label siterecovery.trilio.io/protected-vm=true is stamped on the KubeVirt VirtualMachine object, not on the DRBDResource.

key spec fields (read-only reference)

key status fields

kubectl get columns: Side, Role, Node, State, Phase, Age

ReplicationGroupStatus

Short name: rgs | Namespace: dr-<name> on TSR-Manager

A ReplicationGroupStatus aggregates replication health for a ProtectionGroup into a single resource. The replication-monitor reconciler auto-creates exactly one per ProtectionGroup, named <protection-group-name>-replication. You do not create this resource. Use the label siterecovery.trilio.io/protection-group: <group-name> to filter them — field selectors on spec.* or status.* do not work for custom resources.

spec fields (read-only reference)

key status fields

kubectl get columns: Protection-Group, RPO-Status, Out-Of-Sync, Synced, Connection, Last-Sync, Age

RPOEvent

Short name: rpoe | Namespace: dr-<name> on TSR-Manager

An RPOEvent is an immutable audit record of a single replication event — a connection loss, an RPO violation, a resync start or completion, or a sync-state transition. The replication-monitor creates these automatically. All data is in spec (there is no status subresource). Filter by the label siterecovery.trilio.io/protection-group: <group-name>.

spec fields (read-only reference)

kubectl get columns: Protection-Group, Event-Type, RPO-Seconds, Out-Of-Sync, Reason, Timestamp, Age

Hook

Short name: none | Namespace: dr-<name> on TSR-Manager

A Hook is a reusable, lifecycle-agnostic definition of a customer Job that runs at fixed points of the failover, failback, or DR-test lifecycle. It has no status and no controller. ProtectionGroup.spec.hooks bindings reference Hook objects by name. The Hook admission webhook denies spec edits while an operation is actively using the hook, and denies deletion while it is referenced.

spec fields

kubectl get columns: Image, Timeout, Retries, Age

This section shows the most common patterns for creating and observing the key CRDs. All commands target the TSR-Manager cluster unless stated otherwise.

Querying zone and cluster status

Check your ProtectionZone is Available before creating any zone-scoped resources:

oc get pz -n dr-myzone

Inspect cluster reachability:

oc get pz myzone -n dr-myzone -o jsonpath='{.status.clusters[*].status}'

Creating a ProtectionGroup

Create a ProtectionGroup that bundles two VMs with boot ordering:

apiVersion: siterecovery.trilio.io/v1alpha1
kind: ProtectionGroup
metadata:
  name: web-tier
  namespace: dr-myzone
spec:
  sourceCluster: cluster1
  virtualMachines:
    - name: web-db
      namespace: production
      bootOrder: 1
    - name: web-app
      namespace: production
      bootOrder: 2
  desiredState: running
  sla:
    rtoTargetSeconds: 300
    rpoTargetSeconds: 0

oc apply -f protection-group.yaml -n dr-myzone
oc get pg -n dr-myzone

Protecting a VM

Create a ProtectionRequest for each VM in the group. The VM must be running:

apiVersion: siterecovery.trilio.io/v1alpha1
kind: ProtectionRequest
metadata:
  name: protect-web-app
  namespace: dr-myzone
spec:
  sourceCluster: cluster1
  virtualMachine:
    name: web-app
    namespace: production
  replicationConfig:
    replicationProtocol: C
    rpo: 0
    drbdMetadataConfig:
      storageClassName: fast-ssd
      size: 128Mi

oc apply -f protection-request.yaml -n dr-myzone
# Watch the phase progress
oc get pr -n dr-myzone -w

A VM is fully protected when status.phase reaches Protected. While in Syncing, check progress:

oc get pr protect-web-app -n dr-myzone \
  -o jsonpath='{.status.slowestVolumeSyncProgress}'

To find protected VMs on a workload cluster:

# Run against the workload cluster
oc get vm -A -l siterecovery.trilio.io/protected-vm=true

Monitoring replication health

The replication monitor auto-creates a ReplicationGroupStatus named <pg-name>-replication:

oc get rgs -n dr-myzone
oc get rgs web-tier-replication -n dr-myzone -o yaml

Check the RPO compliance status and out-of-sync data:

oc get rgs web-tier-replication -n dr-myzone \
  -o jsonpath='{.status.rpoStatus} {.status.aggregated.outOfSyncBytes}'

List recent RPO events for a protection group:

oc get rpoe -n dr-myzone \
  -l siterecovery.trilio.io/protection-group=web-tier \
  --sort-by=.spec.timestamp

Check per-VM replication detail on a workload cluster:

# Run against the workload cluster; DRBDResource lives in the VM's namespace
oc get dres -n production

Running a test failover

Create a TestFailover to validate DR without disrupting production:

apiVersion: siterecovery.trilio.io/v1alpha1
kind: TestFailover
metadata:
  name: web-tier-drill-1
  namespace: dr-myzone
spec:
  protectionGroupRef:
    name: web-tier
  cleanupPolicy: Automatic
  retentionTime: 2h
  schedulingCheck: Fail
  verification:
    reachability:
      - type: http
        vmName: web-app
        port: 8080
        endpoint: /healthz
        expectedStatus: 200
        timeout: 30s

oc apply -f test-failover.yaml -n dr-myzone
oc get tfo -n dr-myzone -w

After the test completes, retrieve the test namespace and results:

oc get tfo web-tier-drill-1 -n dr-myzone \
  -o jsonpath='{.status.testNamespace} {.status.result} {.status.schedulingCheck.verdict}'

To keep the test resources for manual inspection, set cleanupPolicy: Manual and trigger cleanup when ready:

oc patch tfo web-tier-drill-1 -n dr-myzone \
  --type merge -p '{"spec":{"cleanupRequested":true}}'

Executing a planned failover

Create a FailoverRequest to move the protection group to cluster2:

apiVersion: siterecovery.trilio.io/v1alpha1
kind: FailoverRequest
metadata:
  name: planned-fo-1
  namespace: dr-myzone
spec:
  protectionGroupRef:
    name: web-tier
  targetCluster: cluster2
  failoverType: planned
  batchBootTimeoutSeconds: 300

oc apply -f failover-request.yaml -n dr-myzone
oc get fr -n dr-myzone -w

Watch per-VM progress:

oc get fr planned-fo-1 -n dr-myzone \
  -o jsonpath='{.status.vmStatuses}'

Executing an unplanned failover

When the primary cluster is unavailable, create a FailoverRequest with failoverType: unplanned. DRBD volumes are force-promoted on the target without waiting for the primary to shut down:

apiVersion: siterecovery.trilio.io/v1alpha1
kind: FailoverRequest
metadata:
  name: emergency-fo-1
  namespace: dr-myzone
spec:
  protectionGroupRef:
    name: web-tier
  targetCluster: cluster2
  failoverType: unplanned

If replication was Healthy and Consistent at the moment of failure, zero data loss occurs. If replication was Degraded, minimal data loss may occur.

Example 1: Minimal ProtectionZone

The smallest valid ProtectionZone with two workload clusters. The storageBackendMode field is required and must be DRBD.

apiVersion: siterecovery.trilio.io/v1alpha1
kind: ProtectionZone
metadata:
  name: zone-east-west
  namespace: dr-zone-east-west
spec:
  displayName: "East-West DR Zone"
  storageBackendMode: DRBD
  clusters:
    - name: primary
      clusterID: cluster1
      distributionName: RHEL-CoreOS-9
      kubeconfigSecretRef:
        name: cluster1-kubeconfig
        key: kubeconfig
    - name: dr
      clusterID: cluster2
      distributionName: RHEL-CoreOS-9
      kubeconfigSecretRef:
        name: cluster2-kubeconfig
        key: kubeconfig

Example 2: ProtectionGroup with boot ordering and SLA

Three VMs that must start in order: database first, then cache, then application. The SLA records compliance targets.

apiVersion: siterecovery.trilio.io/v1alpha1
kind: ProtectionGroup
metadata:
  name: app-stack
  namespace: dr-zone-east-west
spec:
  sourceCluster: cluster1
  virtualMachines:
    - name: app-db
      namespace: production
      bootOrder: 1
    - name: app-cache
      namespace: production
      bootOrder: 2
    - name: app-server
      namespace: production
      bootOrder: 3
  desiredState: running
  sla:
    rtoTargetSeconds: 300
    rpoTargetSeconds: 0
  vmIdentity:
    macAddresses: Preserve

Example 3: ProtectionRequest with custom metadata storage and standby placement

Protect a VM, using a dedicated fast StorageClass for DRBD metadata PVCs and relaxing node affinity on the DR copy.

apiVersion: siterecovery.trilio.io/v1alpha1
kind: ProtectionRequest
metadata:
  name: protect-app-server
  namespace: dr-zone-east-west
spec:
  sourceCluster: cluster1
  virtualMachine:
    name: app-server
    namespace: production
  replicationConfig:
    replicationProtocol: C
    rpo: 0
    drbdMetadataConfig:
      storageClassName: fast-metadata
      size: 128Mi
  standbyPlacement:
    nodeAffinity:
      dropAll: true

Example 4: TestFailover with TCP and HTTP probes

Run a DR drill with automatic cleanup after 4 hours, with a TCP probe on port 5432 (database) and an HTTP health check on the application server.

apiVersion: siterecovery.trilio.io/v1alpha1
kind: TestFailover
metadata:
  name: app-stack-drill
  namespace: dr-zone-east-west
spec:
  protectionGroupRef:
    name: app-stack
  cleanupPolicy: Automatic
  retentionTime: 4h
  schedulingCheck: Fail
  verification:
    reachability:
      - type: tcp
        vmName: app-db
        port: 5432
        timeout: 30s
      - type: http
        vmName: app-server
        port: 8080
        endpoint: /health
        expectedStatus: 200
        timeout: 30s

Example 5: FailoverRequest — planned failover to DR cluster

apiVersion: siterecovery.trilio.io/v1alpha1
kind: FailoverRequest
metadata:
  name: planned-failover-to-dr
  namespace: dr-zone-east-west
spec:
  protectionGroupRef:
    name: app-stack
  targetCluster: cluster2
  failoverType: planned
  batchBootTimeoutSeconds: 300

Example 6: FailoverRequest — unplanned (emergency) failover

For use when the primary cluster is unreachable. Force-promotes on the DR cluster immediately.

apiVersion: siterecovery.trilio.io/v1alpha1
kind: FailoverRequest
metadata:
  name: emergency-failover
  namespace: dr-zone-east-west
spec:
  protectionGroupRef:
    name: app-stack
  targetCluster: cluster2
  failoverType: unplanned

Example 7: Hook definition with a credential volume

A reusable hook that runs a database quiesce script, mounted from a Secret.

apiVersion: siterecovery.trilio.io/v1alpha1
kind: Hook
metadata:
  name: db-quiesce
  namespace: dr-zone-east-west
spec:
  description: "Quiesce the PostgreSQL database before failover"
  timeoutSeconds: 120
  retries: 2
  retryDelaySeconds: 10
  jobTemplate:
    image: quay.io/myorg/db-tools:1.2.3
    command: ["/scripts/quiesce.sh"]
    volumes:
      - name: db-creds
        secret:
          secretName: db-admin-secret
    volumeMounts:
      - name: db-creds
        mountPath: /etc/db-creds
        readOnly: true
    resources:
      requests:
        cpu: 100m
        memory: 64Mi
      limits:
        cpu: 500m
        memory: 128Mi

Bind it to a ProtectionGroup as a pre-failover hook:

# In ProtectionGroup.spec.hooks:
hooks:
  - name: quiesce-db
    hookName: db-quiesce
    type: pre-failover
    runOn: source
    onFailure: Abort
    order: 1

Example 8: Reading DRBDResource status on a workload cluster

Query the DRBDResource for a VM named app-db in the production namespace. Run this against the workload cluster, not the TSR-Manager cluster.

# Switch context to the workload cluster
oc get dres -n production
oc get dres drbd-production-app-db-a1b2c3d4 -n production -o yaml

Check per-volume sync state:

oc get dres drbd-production-app-db-a1b2c3d4 -n production \
  -o jsonpath='{.status.volumes[*].replicationState}'

Example 9: ProtectionZone with runtime log level override

Enable debug logging for the DRBD node agents without changing the control-plane log level:

apiVersion: siterecovery.trilio.io/v1alpha1
kind: ProtectionZone
metadata:
  name: zone-east-west
  namespace: dr-zone-east-west
spec:
  displayName: "East-West DR Zone"
  storageBackendMode: DRBD
  clusters:
    - name: primary
      clusterID: cluster1
      kubeconfigSecretRef:
        name: cluster1-kubeconfig
        key: kubeconfig
    - name: dr
      clusterID: cluster2
      kubeconfigSecretRef:
        name: cluster2-kubeconfig
        key: kubeconfig
  logging:
    level: info
    nodeAgentLevel: debug

The change takes effect within approximately 15 seconds with no pod restarts.

Use the following format for each issue: Symptom, Likely cause, Fix.

Issue 1: ProtectionZone admission denied — Linstor backend is not supported yet; use DRBD

Symptom: oc apply of a ProtectionZone CR returns an admission webhook error containing the message above.

Likely cause: spec.storageBackendMode is set to Linstor.

Fix: Change spec.storageBackendMode to DRBD. This is the only accepted value in Tech Preview.

spec:
  storageBackendMode: DRBD

Issue 2: ProtectionRequest stuck in Failed phase with Validated=False

Symptom: The ProtectionRequest reaches the Validating phase and then transitions to Failed. A Validated=False condition and a warning event describe the rejection.

Likely causes:

• One or more of the VM's disks is not volumeMode: Block.
• The VM is not running at the time of protection (the VM must be running).
• The sourceCluster field references a clusterID that does not match either cluster1 or cluster2.

Fix: Correct the VM configuration or the CR field that the warning event identifies. Delete the failed ProtectionRequest and create a new one—the controller does not retry failed requests.

# Read the event for the exact reason
oc describe protectionrequest <name> -n <namespace> --context=primary-cluster

Issue 3: oc adm drain does not complete on a node hosting a protected VM

Symptom: oc adm drain <node> hangs or reports that eviction of a VM pod was denied.

Likely cause: The node hosts a running protected VM. All KubeVirt migration paths (user-initiated, evacuation, drain) are realised as VirtualMachineInstanceMigration objects, and the TSR admission webhook denies these for protected VMs.

Fix: There is no way to drain a node hosting a running protected VM without first unprotecting the VM. To perform node maintenance:

• For in-place maintenance (reboot, kernel update): proceed with the reboot. DRBD modules reload on boot, the anchor pod returns to the same node, and DRBD reconnects and resynchronises the delta.
• For permanent node replacement: unprotect the VM, perform the node replacement, then protect the VM again (full initial resync required).

Issue 4: TestFailover stuck in CleaningUp or not cleaning up

Symptom: The TestFailover CR has been in CleaningUp for an extended period, or resources remain in the test namespace after the test completed.

Likely cause: cleanupPolicy: Manual was set, or the test failed partway through cleanup.

Fix: Do not patch finalizers. Delete the TestFailover CR through the normal API and the controller will handle cleanup:

oc delete testfailover <name> -n dr-production --context=quorum-cluster

If cleanup is blocked, inspect the test namespace (read from status.testNamespace) for stuck resources:

TEST_NS=$(oc get testfailover <name> -n dr-production \
  --context=quorum-cluster \
  -o jsonpath='{.status.testNamespace}')

oc get all -n "$TEST_NS" --context=dr-cluster

Issue 5: FailoverRequest transitions to Failed before completing

Symptom: The FailoverRequest transitions from InProgress directly to Failed.

Likely causes:

• The failover exceeded the 5-minute wall-clock budget.
• VMs failed to start on the target cluster within batchBootTimeoutSeconds.
• DRBD volume promotion failed on the target side.

Fix:

1. Check per-VM detail in status.vmStatuses:

oc get failoverrequest <name> -n dr-production \
  --context=quorum-cluster \
  -o jsonpath='{.status.vmStatuses}'

2. Check the failover-controller logs on the quorum cluster:

oc logs -l app.kubernetes.io/part-of=site-recovery,app.kubernetes.io/component=quorum-control-plane \
  -n dr-production \
  --context=quorum-cluster \
  -c manager

3. Check DRBD resource state on both workload clusters:

oc get drbdresource -n <vm-namespace> --context=primary-cluster
oc get drbdresource -n <vm-namespace> --context=dr-cluster

4. If the primary cluster is unreachable and you used failoverType: planned, re-apply the request with failoverType: unplanned to force-promote without waiting for the primary.

Issue 6: ReplicationGroupStatus shows Degraded or Critical

Symptom: oc get replicationgroupstatus reports Degraded or Critical health for a Protection Group.

Likely causes:

• Network connectivity between primary and DR worker nodes on TCP ports 7000–8000 has been interrupted.
• The DRBD node agent on a worker node is not running or has not converged (check for the siterecovery.trilio.io/not-ready:NoSchedule taint on nodes).
• A worker node hosting a protected VM was lost.

Fix:

1. Check RPOEvent records for the affected group:

oc get rpoevent -n <vm-namespace> --context=primary-cluster

2. Check node agent DaemonSet pod status on both workload clusters:

oc get pods -l app.kubernetes.io/part-of=site-recovery,app.kubernetes.io/component=workload-control-plane \
  -n <agent-namespace> --context=primary-cluster

oc get pods -l app.kubernetes.io/part-of=site-recovery,app.kubernetes.io/component=workload-control-plane \
  -n <agent-namespace> --context=dr-cluster

3. Check for the node taint:

oc get nodes --context=primary-cluster \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.taints}{"\n"}{end}'

4. If a node was permanently lost, follow the node-loss recovery runbook at docs/runbooks/drbdresource-node-loss.md. Remove only the agent finalizer—removing the placement finalizer will permanently leak a PVC/PV pair.

Issue 7: replicationProtocol: A rejected at admission

Symptom: Applying a DRBDReplicationPolicy with drbdProtocol: A results in an admission error: ReplicationProtocolA is not supported yet.

Likely cause: Protocol A (asynchronous replication) is not supported in Tech Preview. The DRBDReplicationPolicy is also created automatically by the ProtectionZone controller—you should not be creating it manually.

Fix: Do not create or modify DRBDReplicationPolicy objects. The ProtectionZone controller creates the default policy (<zoneName>-default) automatically when the zone reaches Available. Only synchronous replication (Protocol C, RPO=0) is supported in Tech Preview.

Issue 8: Collecting a diagnostic bundle

Symptom: You need to provide a support bundle to Trilio support.

Fix: Run tsr-gather via oc adm must-gather against the quorum cluster. This collects logs, CRD state, and configuration from all clusters in the DR estate without capturing secrets or credentials:

oc adm must-gather \
  --image=quay.io/triliovault/tsr-gather:latest \
  --context=quorum-cluster \
  -- /usr/bin/tsr-gather

The resulting bundle in ./must-gather.local.* can be shared with support.