Start with the replication session, not assumptions
Identify the affected replication session, source and destination resources, current state, last successful synchronization, and whether the problem affects one session or many. A single failed session often points to a resource-specific issue; many failures can indicate connectivity, system health, credentials, or a broader remote-system problem.
Check both systems for health and reachability
Review active alerts and system health on both Unity systems. Confirm replication interfaces and routes are available and that the remote system relationship is healthy. If networking changed recently, validate VLANs, gateways, MTU assumptions, firewall rules, and the path in both directions.
Separate network failures from storage failures
Use the platform health information and supported connectivity tests to determine whether the remote system is reachable. Then check pool capacity, resource state, replication interfaces, and any recent configuration changes. Avoid repeatedly deleting and recreating a session before identifying the underlying failure.
Protect recoverability while troubleshooting
Before making disruptive changes, document the current replication state and understand which copy is authoritative. If the workload has a strict RPO or DR requirement, treat changes to replication relationships as production changes with a rollback plan.
When to escalate
Escalate when the issue involves persistent system faults, unexplained replication state transitions, suspected software defects, or a recovery action that could affect the authoritative data copy. Gather timestamps, alerts, session details, software versions, and relevant support bundles first.
This article is a general troubleshooting framework. Validate commands and procedures against your platform version, vendor documentation, support requirements, and change-control process before making production changes.