Veeam CDP and Universal CDP in v13: Near-Zero RPO for VMware and Beyond

What CDP Is and Why It Matters

Standard backup and replication jobs run on a schedule. Even a 15-minute replication interval means your worst-case data loss is nearly 15 minutes of transactions. For mission-critical workloads like financial systems, trading platforms, healthcare records, or anything where the answer to "how much data can you afford to lose?" is measured in seconds rather than minutes, scheduled replication is not enough.

Continuous Data Protection solves this by eliminating the schedule entirely. Instead of periodic snapshots, CDP captures every I/O write as it happens and replicates it to the recovery site continuously. The recovery point is always current. In practice, Veeam CDP achieves RPOs measured in seconds, not minutes or hours. And because the replica is always synchronized, RTO at failover is also minimal: the replica powers on immediately without needing to apply a backlog of changes.

In VBR v13, CDP covers two distinct use cases: VMware CDP for vSphere workloads (first shipped in v11, substantially matured since), and Universal CDP, introduced in v13 as a major new capability that extends near-zero RPO protection to physical Windows and Linux machines, cloud VMs, and any workload reachable by the Veeam agent regardless of hypervisor.

How Veeam CDP Works: VAIO and the Journal

VMware CDP is built on VMware's vSphere APIs for I/O Filtering (VAIO). VAIO is a framework that allows certified software to intercept disk I/O operations at the hypervisor level before they are written to the datastore. Veeam installs an I/O filter (also called a VAIO filter or storage policy) on your vSphere cluster. Once the filter is applied to a VM's storage policy, every write that VM makes to its virtual disks is intercepted, captured, and sent to the VMware CDP Proxy before it reaches the datastore.

The CDP Proxy receives this continuous stream of I/O data and forwards it to the replica on the target datastore. The target maintains a journal of recent writes, which is how point-in-time recovery is possible even with continuous replication. If you need to recover to a state from 10 minutes ago rather than right now (for example, to recover before a ransomware encryption event began), you roll back the journal to that point.

The critical distinction from snapshot-based replication: no snapshots are created on the source VM during normal CDP operation. The I/O filter intercepts data before the snapshot layer. This means no snapshot overhead, no snapshot consolidation events, and no performance impact from growing snapshot delta files. CDP is always-on with near-zero overhead on the source VM.

CDP vs. Snapshot-Based Replication

Snapshot-based replication is the right tool for most VMs where an RPO of 15 minutes or better is acceptable. CDP is for the tier of workloads where that is not enough. Using CDP for every VM in an environment is not the right approach: the network bandwidth and storage overhead of continuous replication at scale adds up quickly. Identify your true Tier 1 workloads, protect those with CDP, and use scheduled replication or backup for everything else.

VMware CDP: Requirements and Hard Limits

Configuring VMware CDP Policies

CDP is configured through CDP Policies rather than standard backup or replication jobs. In the VBR console, navigate to Home > CDP Policies and click CDP Policy to launch the creation wizard.

VM selection: add the VMs you want to protect. One VM can belong to only one CDP policy. If a VM is already in a CDP policy, it cannot be added to another. VMs must be powered on at the time the CDP policy first starts. VMs with IDE hard drives require a brief power-off before the initial synchronization, as the I/O filter storage policy must be applied before the VM restarts.

Target configuration: specify the target vCenter, cluster, host, datastore, and network for the replica VMs. The target cluster must support the hardware versions of the source VMs. Thick-provisioned disks require double the target storage during initial synchronization: a 500 GB thick-provisioned disk needs 1 TB available on the target datastore at sync start. Once initial sync completes, the extra space is released.

RPO settings: set the target RPO in seconds. Veeam uses this as a target, not a guarantee. The actual RPO achieved depends on network bandwidth, write I/O rate on the source VM, and CDP Proxy capacity. Monitor achieved RPO in the CDP policy session view. If sustained achieved RPO exceeds your target, investigate network bandwidth and proxy capacity first.

Journal settings: configure short-term retention (how many hours of continuous restore points to maintain in the journal, up to 168 hours) and long-term restore point schedule (periodic snapshots of the replica for longer retention, up to 95 per disk). Long-term restore points are created by Veeam from the current replica state on a schedule you define, typically daily or weekly, and are kept for a defined retention period.

Short-Term and Long-Term Restore Points

CDP generates two categories of restore points that serve different recovery scenarios.

Short-term restore points live in the journal maintained on the target datastore. They represent a continuous stream of recovery points from the current moment back through the configured journal window (up to 168 hours). When you need to recover a VM to any point in the past 7 days, you use a short-term restore point. The granularity is seconds: you can recover to a state from 4 hours, 23 minutes, and 47 seconds ago. This is the core CDP value proposition for ransomware recovery: pick the exact moment before the encryption event began.

Long-term restore points are periodic snapshots of the replica VM captured by Veeam on a schedule. They live outside the journal and are retained independently of the short-term journal window. Long-term restore points let you recover to a state from last Tuesday, or last month, regardless of the short-term journal window. They are crash-consistent snapshots of the replica, not continuously journaled, so their granularity is determined by your snapshot schedule (daily, weekly, etc.) rather than seconds.

SureReplica: Testing CDP Without Interruption

SureReplica is the CDP equivalent of SureBackup. It verifies that your CDP replica can actually boot and function without interrupting the active CDP policy. SureReplica powers on the replica VM in an isolated network environment (a virtual lab), verifies heartbeat, and optionally runs application test scripts, then discards the test and returns to normal replication. The CDP policy continues running during SureReplica verification: the two do not conflict.

Schedule SureReplica runs regularly, at minimum monthly and ideally weekly for critical workloads. A CDP replica that has never been tested is a promise, not a guarantee. SureReplica turns the promise into a verified assertion with a test log.

Failover and Failback

When the source VM or source site fails and you need to activate the replica, initiate a failover from Home > Replicas in the VBR console. Select the target replica and choose Failover Now. You are presented with a list of restore points: the most recent short-term point (seconds old), or any earlier point in the journal or long-term restore points. Select the appropriate recovery point and confirm.

The replica powers on at the selected restore point. The source VM role is now served by the replica. At this point the CDP policy is paused: replication cannot run in reverse automatically.

When the source VM is repaired and you are ready to return to it, initiate failback from the VBR console. Veeam synchronizes all changes that occurred on the replica back to the source VM, then allows you to commit the failback. After commit, the source VM is live again and CDP replication resumes from source to target. If the source VM cannot be repaired, use Permanent Failover to designate the replica as the permanent source going forward.

Note that Storage vMotion of replica VMs on the target datastore is not permitted while CDP is active. Host vMotion (live migration between hosts within the same cluster) is allowed, and CDP replication continues through it. Migrating a replica's storage with Storage vMotion breaks the CDP relationship and is blocked by Veeam.

Universal CDP: What Changed in v13

Universal CDP is the headline new capability in Veeam v13 for the CDP story. Where VMware CDP is restricted to vSphere VMs and depends on the VAIO framework, Universal CDP extends near-zero RPO protection to any machine that can run the Veeam CDP agent: physical Windows and Linux servers, VMs on any hypervisor, cloud instances on AWS, Azure, or GCP.

The agent-based approach replaces the hypervisor-level I/O filter with a kernel-level volume filter driver installed directly on the protected machine. The driver intercepts writes at the volume level within the OS, captures the I/O stream, and forwards it to the Veeam CDP infrastructure for delivery to the replica. From the recovery side, the target is a VMware vSphere environment: Universal CDP replicates the workload into a vSphere replica VM regardless of the source platform.

The practical implication: you can now run Universal CDP on a bare-metal SQL Server, a Hyper-V VM, a physical Linux database host, or an AWS EC2 instance, and maintain a continuously synchronized vSphere replica that can be failed over to in seconds. This brings CDP-class protection to workloads that the VAIO framework could never reach.

Universal CDP: Requirements and Limitations

Configuring Universal CDP Policies

Universal CDP policies are created similarly to VMware CDP policies but source from protection groups rather than directly from a VM inventory. The workflow:

1. Create a Protection Group: define a protection group containing the physical or non-vSphere machines you want to protect. Protection groups are configured under Inventory > Physical Infrastructure. Add machines by IP address, hostname, Active Directory OU, or CSV. Veeam deploys the Veeam CDP Agent Service and Volume Filter Driver to each machine in the group automatically.

2. Create the CDP Policy: navigate to Home > CDP Policies and create a new policy, selecting the protection group as the source. Configure the target vSphere environment (ESXi 8.0+, vCenter, datastore, network), RPO target, short-term journal window, and long-term restore point schedule exactly as with VMware CDP.

3. Initial Synchronization: the initial sync transfers the full disk content of each protected workload to the target vSphere environment. This can be substantial for large workloads. Plan the initial sync during a low-traffic window, and ensure network bandwidth is adequate. After initial sync completes, only changed I/O blocks are sent continuously.

Choosing Between VMware CDP and Universal CDP

Key Limitations Reference

VMware CDP only: physical RDM and SCSI bus sharing not supported. Virtual RDM (vRDM) is supported. Storage vMotion of replicas blocked. Replicas cannot be manually powered on. VMware encryption with I/O filters requires the Allow I/O filters before encryption parameter set to True in the storage policy. Data encryption rules do not apply to traffic between ESXi hosts and the CDP Proxy (that traffic is handled separately from standard VBR encryption policies).

Universal CDP only: source can be any platform, but the target must be vSphere ESXi 8.0 or later. CSV and Windows Storage Spaces not supported. 4K native disks not supported. Policy disable/rescan/reboot cycle required when adding workloads to an active policy.

Both CDP variants: powered-off VMs or workloads cannot be protected (CDP requires the workload to be running to capture I/O). Initial snapshot conflict restriction applies: no existing snapshots when the policy first starts. One VM or workload per CDP policy. Maximum 95 long-term restore points per disk. One cluster per backup server for I/O filter management.