Overview

If a Virtual Protection Group (VPG) repeatedly goes out of sync in DR2Cloud, it typically indicates that the replication engine cannot keep up with the rate of change on the protected workload.

DR2Cloud uses continuous data protection powered by HPE Zerto, which replicates changes in near real time to maintain a journal of recovery points.

When the volume or speed of data change exceeds available resources, the VPG may fall out of sync until it can catch up.

Most common cause: Bandwidth constraints

The most frequent reason for VPGs going out of sync is insufficient available bandwidth between the source environment and the DR2Cloud Recovery Virtual Data Centre (RVDC).

Key point

Each DR2Cloud RVDC is provisioned with 100 Mbps internet bandwidth as standard

This bandwidth is shared with replication traffic and other services unless increased

This is defined within the DR2Cloud service description and pricing model.

When this becomes an issue

VPGs are more likely to fall out of sync when:

• The protected workload has a high change rate (high IOPS or large data writes)
• Multiple VMs are grouped into a single busy VPG
• There are peak activity periods such as backups, batch jobs, or reporting
• The available bandwidth is saturated for sustained periods

Workloads that require special consideration

Certain workloads are significantly more demanding from a replication perspective.

Database servers

If the protected VM is running a database engine such as:

• Microsoft SQL Server
• Oracle Database

These systems generate continuous, high-volume write activity, which can quickly saturate bandwidth if not configured correctly.

Mandatory best practice

For database workloads, you must follow vendor and Zerto-specific best practices to ensure stable replication and avoid unnecessary churn.

Refer to the official guidance:

• https://help.zerto.com/bundle/BP.MS.SQL.Server/page/Protecting_Microsoft_SQL_Server.htm
• https://help.zerto.com/bundle/BP.Oracle.HTML/page/Zerto_Virtual_Replication_and_Oracle_Best_Practices_R.htm

Failure to follow these recommendations can significantly increase write amplification and replication load, leading to frequent out of sync conditions.

Other contributing factors

While bandwidth is the primary cause, other factors can contribute:

1. High change rate spikes

Short bursts of heavy write activity can temporarily exceed available capacity, especially during:

• Database maintenance tasks
• Patch cycles
• Backup operations

2. VPG design

• Grouping too many high-change VMs in a single VPG
• Lack of prioritisation for critical workloads

3. Network stability

• Packet loss or latency between sites
• Intermittent connectivity issues

How to resolve the issue

1. Validate bandwidth utilisation

• Check current throughput during peak periods
• Compare against the 100 Mbps baseline

2. Increase available bandwidth

• Request additional bandwidth to the RVDC via service request
• Right-size connectivity based on workload behaviour

3. Optimise database workloads

• Apply Zerto best practices for SQL or Oracle
• Reduce unnecessary disk churn where possible

4. Review VPG design

• Split high-change workloads into separate VPGs
• Prioritise critical systems

5. Monitor ongoing behaviour

• Track RPO compliance and journal lag
• Identify patterns tied to workload activity

Summary

A VPG going out of sync is not typically a platform fault. It is usually a sign that:

• The rate of data change exceeds available bandwidth, or
• The protected workload has not been optimised for continuous replication

Given DR2Cloud includes 100 Mbps internet connectivity as standard within the RVDC, environments with higher change rates must be sized and configured accordingly to maintain continuous protection.

When to escalate

If the issue persists after:

• Confirming sufficient bandwidth
• Applying database best practices
• Reviewing VPG design

Raise a support case with Assurestor including:

• VPG name(s)
• Timeframes of sync loss
• Any recent workload or infrastructure changes