4433 The recovery point objective (RPO) for the volume group has been exceeded.

Explanation

The achieved RPO of the volume group exceeds the RPO that the replication policy defines. This condition can occur due to one or more of the following:
  • The partnership that is required for disaster recovery replication is disconnected.
  • Host write throughput has increased and now exceeds the effective capability of the partnership.
  • The DR partnership has insufficient bandwidth. The system can throttle partnership bandwidth, which can cause this condition. View the current link bandwidth in lspartnership (link_bandwidth_mbits) and change it with chpartnership using the -linkbandwidthmbits option.
  • One or both systems are experiencing performance issues.
Note: If host write activity is unusually high, the condition might clear when activity decreases. You can use monitoring tools, such as IBM Storage Insights, to identify issues.

Synchronous disaster recovery behavior: When using synchronous disaster recovery, if the partnership is disconnected for longer than 15 seconds and then reconnects, or if slow I/O persists for 15 seconds, replication of the volume group is suspended for 5 minutes. In this case, expect at least 5 minutes for re‑synchronization. Once synchronized, the RPO (which is zero for synchronous DR) is met and the event is automatically fixed.

User response

  1. Identify the configuration and topology.
    • Use lsvolumegroup to obtain the replication_policy_id for the affected volume group.
    • Use lsreplicationpolicy to confirm the policy topology (2-site-async-dr, async-dr, or sync-dr).
  2. Identify the relevant partnership.
    • For 2-site-async-dr: Use lsreplicationpolicy and read location1_system_id and location2_system_id to identify the remote system; that remote system corresponds to the partnership you must verify.
    • For async-dr or sync-dr:
      • From lsvolumegroup, get the partition_id, then use lspartition to check dr_linked_remote_system_1_id and dr_linked_remote_system_2_id.
      • If two DR‑linked remote systems exist (HA recovery partition), use lsvolumegroupreplication to read upper_partition_active_management_system_id and select the partnership with that AMS.
  3. Restore connectivity if disconnected.
    • Verify the partnership status in lspartnership.
    • Resolve network, routing, fabric, or authentication issues until the partnership is connected.
  4. Validate and, if needed, increase effective bandwidth.
    • Review lspartnership (link_bandwidth_mbits).
    • If throttled or insufficient, adjust using chpartnership -linkbandwidthmbits and consider installing additional links or otherwise increasing available bandwidth.
  5. Assess workload and system performance.
    • If host write throughput recently increased, the condition might self‑resolve as load subsides.
    • Investigate system performance issues on both sides; use IBM Storage Insights or other monitoring tools to locate bottlenecks.
  6. Review RPO targets for achievability.
    • If the current network and system configuration cannot meet the defined RPO, change to a replication policy with a higher (less strict) RPO and apply it to the volume group using chvolumegroup.
    • When the previous replication policy is no longer in use, delete it with rmreplicationpolicy.
  7. For synchronous DR (sync‑dr).
    • If a 15‑second disconnect or 15‑second slow‑I/O period occurred, allow at least 5 minutes for the automatic replication suspension to expire and for the volume group to re‑synchronize. The event is automatically fixed when synchronization completes and the RPO is within target (zero).