Monitoring & Troubleshooting
Ongoing DR readiness depends on healthy replication and fresh recovery points. This page covers what to watch and how to resolve common problems.
What to monitor
- Replication status — each protected workload should be actively replicating (or intentionally paused).
- Last successful sync — how recently the workload last replicated.
- Recovery-point age — the time since the newest recovery point. This is your effective data-loss exposure if a disaster happened now.
- Recovery-point count — that the expected number of recovery points exists at the DR site.
- Site pairing status — both Cockpit and DRM peers should read connected / paired.
The DRM Overview shows aggregate DR health across all protected workloads, and the Workloads view shows per-workload status.
Understanding replication states
| State | Meaning |
|---|---|
| Replicating / Idle | Healthy; syncing on schedule or waiting for the next cycle |
| Paused | Intentionally paused; not accumulating new recovery points |
| Degraded | The most recent sync did not fully reach the recovery site; it will be retried |
| Failing over / Failed over | A failover is in progress or has completed |
| Error | An operation failed and needs attention |
A degraded status is honest, not silent
If a replication cycle cannot transfer to the recovery site, it is reported as a failure and does not create a usable recovery point. That means the status you see reflects the data that is actually recoverable — treat a persistent degraded/error state as an exposure to resolve promptly.
Common issues
A workload's recovery point is not advancing
- Confirm the workload is not paused (a paused workload does not create new recovery points — resume it).
- Confirm the site pairing is connected and the sites are reachable on ports
7770/7771/7772. - Check for a degraded status, which indicates the cross-site transfer is failing; resolve the connectivity or storage cause and it will retry.
Failover or test failover is disabled (greyed out)
- The Disaster Recovery entitlement is not enabled on that Cockpit — check licensing at that site.
- The workload has no active replication job, or an operation is already in progress.
"No replica available for failover"
- The recovery point has not completed at the recovery site — confirm the baseline finished and a recovery point exists there.
- Verify the recovery-site storage pool is reachable by the hypervisor process (a restricted pool can prevent the recovery disk from opening).
Emergency failover is refused
- DRM detected the source workload is still reachable and running, and refused to avoid a split-brain (the same workload live at both sites). Confirm the primary is genuinely down, or use the explicit override only when you are certain it is safe.
Pairing shows "Invalid token" or fails to connect
- The API access token expired or was revoked — create a new durable token on the remote site and re-register the pairing.
- Verify the remote site was registered by a routable IP, not loopback, and that the inter-site ports are open.
Before you need it: rehearse
The single best way to avoid a surprise during a real disaster is to run a test failover regularly. It is non-disruptive, exercises the whole recovery path, and confirms the workload — every disk included — actually boots at the recovery site. See Failover & Recovery.