Introduction
When using CDP and attempting to complete the initial sync for a virtual machine, the initial sync may complete with the following error:
- Restore point creation completed with errors. (Failed to create the initial long-term restore point at <timestamp>) Error: Disks traffic is not clean
The initial sync process for CDP is when it copies all of the data for a virtual machine from the client side to the target side, creating a working replica of the VM as an initial “restore point”. This restore point is basically a working VM replica on the target size that can be used in a failover situation to boot the VM. Once the initial sync has completed, the status for that VM should then go to “syncing”, which means CDP is now synchronizing incremental changes in the VM.
The Issue
Sometimes after the initial sync completes, the VM synchronization process may go into a failed state with the following error:
- Restore point creation completed with errors. (Failed to create the initial long-term restore point at <timestamp>) Error: Disks traffic is not clean
The most common issue with this is a backup or replication job that has taken place during the CDP initial sync process that took a snapshot of the VM. During the CDP initial sync process, no snapshots of the VM can exist or be taken from any source, this includes any Veeam or VMware tasks that take snapshots or any pre-existing snapshot of the VM.
Per Veeam’s documentation:
https://helpcenter.veeam.com/docs/backup/vsphere/cdp_requirements.html?ver=120
“VMs that you plan to protect must not have snapshots at the moment the CDP policy starts for the first time.”
If a snapshot is taken while the CDP initial sync is taking place, CDP doesn’t just fail (even though it’s not going to work anyway), CDP continues to try to complete the process, but now it’s in a perpetual behind state because of the snapshot and the sync process runs much slower. Then each time the backups with snapshots runs again and again, which has a cumulative slowness effect on CDP, so it just gets slower and slower to a crawl, then when it finally copies everything at the end, it is so far behind it can never catch up, so it then has a perpetual disk traffic not clean.
Solution
Verify no snapshots exist when the VM’s initial sync process is taking place and confirm that no other jobs or policies will run that may create a snapshot of that VM. If a VM was replicated and is now in a failed state, that replica must be deleted from the “Replicas” section before attempting to start the CDP sync again.
Conclusion
As part of the initial sync process, CDP attempts to make a replica of the VM on the target side, which is basically a one-to-one copy of the existing VM. When a snapshot is taken on the source side, the VM’s disk is placed in a read-only state and a delta file is created to record all of the changes. This changes the disk’s state, thus the I/O flow that CDP is monitoring is disrupted, and CDP cannot continue to accurately track and replicate the changes since the I/O flow has now changed. Furthermore, the target replica doesn’t detect these changes immediately, resulting in a mismatch between the source and destination size. Veeam now tries to restart the process but ends up in basically a failed loop state.
