A completed synchronisation can leave an RPO violation because its recovery point represents the VM when synchronisation started, not when transfer finished. Compare the age of the latest available instance with the configured Recovery Point Objective (RPO), then investigate why newer instances become available too late.
This article uses the vSphere Replication 9.0 documentation. It is source-only analysis: the timeline is illustrative, and no replication, recovery or performance test was run.
The two times that matter
RPO expresses the maximum tolerable age of recoverable data. It is not a command to run replication at that interval. vSphere Replication estimates transfer duration from recent instances and schedules work to meet the objective. A16-D1
An instance has a source-state time and an availability time. During transfer, a newer source state exists but is not yet an available recovery point at the destination. This is why “the job finished two minutes ago” is not an adequate recovery-age measurement.
For a diagnostic, obtain the configured RPO, existing instance or job timestamps, transfer durations, historical transferred bytes and site connectivity information. Identify the VM and direction of replication. Keep time zones explicit; a source log in local time and a report in UTC can produce a false gap.
Work through a violation window
The following follows the timing mechanism documented for version 9.0, using synthetic observations:
| Time | Event | Latest available source state |
|---|---|---|
| 12:00 | Synchronisation A starts | Earlier instance |
| 12:10 | A completes; B starts | 12:00 |
| 12:15 | A reaches the 15-minute RPO boundary | 12:00 |
| 12:20 | B completes | 12:10 |
Between 12:15 and 12:20, the available instance is too old. Transfer was active throughout much of that interval, but activity does not make unfinished data an available recovery point. At 12:20 the available instance is ten minutes old, not zero minutes old. A16-D1
Broadcom also explains that, in its 15-minute RPO example, a 7.5-minute transfer duration requires continuous transfers; longer durations produce periodic violations. This is a scheduling illustration, not a universal throughput benchmark or a guarantee that every workload with a shorter duration meets its objective.
Do not calculate recovery age by subtracting the completion time from the current time. Use the source-state time represented by the latest available instance. If the available report does not expose the necessary timestamps, retain that evidence gap rather than estimating an exact recovery point.
Explain the delay using reports
In version 9.0, inspect existing replication reports under the Site Pair tab. Correlate RPO violations with transferred bytes over the same VM and time period. Site-wide totals can hide one high-change VM or a small set of slow destinations. A16-D2
A sustained rise in transferred bytes alongside violations suggests that change volume or shared capacity deserves investigation. Ask whether the application workload changed. It does not prove that the WAN is saturated: recovery-datastore delays and site connectivity problems are also documented causes.
Low transferred bytes with violations is not automatically healthy. Transfer might be unable to make progress. Check the existing site connectivity history, appliance availability evidence and recovery-side storage incident record before requesting additional bandwidth.
This produces a discriminating next question. “Did change volume rise at the same time?” and “Did the recovery datastore stop accepting writes?” lead to different investigations. A single aggregate percentage cannot answer either.
Treat initial synchronisation separately
After a long full synchronisation, blocks changed during that work still need to be transferred. The first incremental can therefore take longer than the configured RPO. Version 9.0 documents immediate subsequent incrementals until an instance satisfies the schedule. A16-D1
Separate this catch-up phase from a steady-state regression. Record when initial synchronisation ended and whether recovery-point age is decreasing across subsequent completed instances. Do not dismiss repeated violations indefinitely as normal catch-up; the observed trend must support that explanation.
Changing the RPO to suppress an alarm changes the tolerated data-loss objective. It does not make the same recovery point newer. That decision belongs with the application owner and the approved recovery requirements.
The 9.0 statistics guide lists a less aggressive RPO or increased bandwidth as possible responses to sustained transfer demand. A less aggressive RPO is a documented design option only when the application owner accepts the larger tolerated data-loss window; changing it solely to hide an alarm would not establish that the original objective was met. This article does not claim independently checked 8.x applicability.
Acceptance and safe limits
A completed diagnosis reconstructs at least one violation window, identifies the corresponding available instance and ranks probable causes using matching report intervals. After a separately approved correction, proposed acceptance is sustained compliance through a representative workload period, including the busiest relevant interval.
Neither an RPO-compliant status nor a completed transfer proves that the application will start correctly after recovery. Application recoverability needs its own qualified validation; it is not inferred here.
The inspection has no configuration rollback. Do not force synchronisation, deactivate protection or trigger a recovery to reproduce this example. Preserve the original RPO and report history when handing the evidence to the recovery owner.
Learning notes
- Recovery-point age starts at the represented source state.
- Transfer completion and recovery freshness are different facts.
- RPO reports suggest causes; they do not identify one bottleneck alone.