Connect the dots to uncover Replication RPO violations

The recovery point objective (RPO) reflects the frequency of replication; shorter RPOs mean more frequent replication, and less data is changed or lost since the last replication cycle. VMware's Sphere Replication 6 can provide adjustable RPOs as short as 15 minutes and as long as 24 hours.

There are times when an administrator will have to deal with error messages about an RPO violation when trying to replicate a virtual machine. However, this type of trouble can often be a misnomer. Even though the error messages in Replication may indicate an RPO violation, the actual issue is usually related to a connectivity or communication problem between elements of the Replication infrastructure -- and nothing to do with the setup or configuration of recovery points themselves.

For example, RPO violations may occur if the vSphere Replication server's IP address has been changed without updating the source systems to use the new IP address. In a situation like this, update the configuration of the replication so any sources refer to the new IP address. Replications might also fail if vSphere Replication is unable to access key ports such as port 80 on storage hosts. These might appear as "forbidden" HTTP connections in log entries. Administrators should make sure any vSphere Replication appliances have access to the proper ports.

Problems can also be traced to the network, such as connectivity or bandwidth problems between source and Replication servers. Some RPO errors might also occur from storage problems such as issues with the Replication server unable to access the target system's data store. Network, connectivity or storage access problems can usually be identified through system logs. For example, the vmkernel.log file on the vSphere Replication server might reveal connectivity problems, while the hbrsrv file in the /var/log/vmware/ folder of the target site's Replication appliance might show issues with attempts to access data stores.