Veeam v13 Universal CDP: Configuring Continuous Data Protection from Scratch

Traditional snapshot-based replication has a ceiling. You schedule intervals, stun VMs, ship changed blocks, and hope the window is tight enough. For most workloads that is fine. For your Tier 1 database servers, your payment processing VMs, or your file-serving infrastructure - it is not. Universal CDP in Veeam v13 removes that ceiling entirely.

This article walks through Universal CDP end to end: what it is, how the engine works, what you need to stand it up, how to configure a policy from scratch, and the gotchas that will burn you if you skip the prep work.

---

What Is Universal CDP and Why Does It Exist

CDP for VMware vSphere has been in Veeam since version 11. It uses vSphere APIs for I/O Filtering (VAIO) to intercept writes on the hypervisor layer and ship them to a replica - no snapshots, near-zero RPO, continuous. The catch was the source had to be a VMware virtual machine. Physical servers, Hyper-V VMs, cloud instances, anything outside of vSphere was excluded.

Universal CDP, introduced fully in v13, drops that constraint. The source can be any Windows or Linux machine - physical server, VM on any hypervisor, or cloud instance. The target stays on VMware vSphere or VMware Cloud Director. You get the same RPO characteristics as native vSphere CDP, now across heterogeneous environments.

Both flavors produce crash-consistent short-term restore points on a journal-based timeline. Short-term retention maxes out at 7 days (168 hours). Long-term restore points are scheduled snapshots of the replica that you retain on a defined schedule - useful for compliance and for rolling back to a point that predates corruption.

---

Architecture: What Moves Data and Who Coordinates It

Understanding the component map before you touch the console saves a lot of troubleshooting time. Universal CDP has five moving parts on the data path.

CDP Coordinator Service

Runs on the VBR backup server. This is the brain of the operation. On initial policy startup it reads policy settings, queries vCenter for target host information, creates empty replica VMs with empty virtual disks, and pushes configuration to every other component. It selects which CDP proxies handle which workloads, enforces RPO and retention settings, and handles reconfiguration events - proxy goes offline, vMotion fires, disk added to source, etc.

CDP Agent Service and Volume Filter Driver

These two components install on each source workload. The Volume Filter Driver hooks into the OS kernel and intercepts I/O transactions between the operating system and the storage volumes. Every write is captured in flight and handed off to the CDP Agent Service. The Agent Service aggregates the captured data, maintains the disk layout, and pushes the data stream to the source CDP proxy. The driver requires a reboot of the source machine after installation.

CDP Proxies

A CDP proxy is a Windows or Linux server assigned the proxy role in VBR. Proxies operate as data movers. The source proxy receives the I/O stream from the Agent Service, prepares it for short-term restore points, compresses and optionally encrypts the data, and ships it to the target proxy. The target proxy receives that data and writes it to the replica disks on the vSphere target.

The minimum deployment is two proxies: one source-side, one target-side. CDP proxies default to storing in-flight data in RAM. The memory allocation model is: if the proxy has 16 GB RAM or less, 50% goes to the OS and 50% to CDP data processing. If RAM exceeds 16 GB, the first 8 GB is reserved for the OS and everything above that is available for CDP. Each disk being protected requires at least 1 MB of proxy RAM allocation.

When RAM fills, the proxy spills to a local disk cache. A larger disk cache allows longer network outages before the CDP policy drops from continuous mode to CBT (Changed Block Tracking) mode - so do not treat the proxy disk cache as an afterthought. If both RAM and cache are exhausted and no other proxy is available, the protective throttling mechanism engages and throughput degrades. Size proxies for your disk count and write rate up front.

I/O Filter on the Target vSphere Cluster

Even in Universal CDP the target side is still vSphere. The target cluster needs the Veeam I/O filter (VAIO-based) installed. This is the same filter used for native CDP for vSphere. It handles incoming data from the target proxy and writes it to the replica virtual disks. It also communicates with the CDP Coordinator to notify it of infrastructure changes.

Architecture Flow

---

Short-Term and Long-Term Restore Points

CDP maintains two classes of restore point. Understanding the difference matters for retention planning.

Short-term restore points are crash-consistent snapshots of the replica built continuously from the incoming I/O stream. They are stored in a journal on the target datastore. The journal holds up to 168 hours (7 days) of history. RPO defines how frequently a new short-term point is committed. The minimum RPO is 2 seconds. The practical minimum for policies covering many high-write VMs is 15 seconds. Maximum is 60 minutes. Short-term points are crash-consistent only - application-consistent points are not supported for Universal CDP.

Long-term restore points are scheduled replicas that persist beyond the 7-day short-term window. You define a schedule (hourly, daily, weekly) and a retention count. These are managed by the CDP Coordinator Service. Maximum long-term restore points per disk is 95. Long-term points are crash-consistent for Universal CDP - application-consistent scheduling is not available at this time.

---

Prerequisites Before You Start

Running through this list before touching the wizard saves you from mid-deployment failures.

Infrastructure Requirements

One Cluster Per Backup Server Rule

Each vSphere cluster can only have the I/O filter managed by a single VBR server. If you add a cluster to a second VBR server and install the I/O filter on it there, CDP policies on the first server fail. This is not a soft recommendation - it is a hard constraint enforced by the filter management infrastructure.

Source Workload Constraints

• !One workload can only belong to one CDP policy. You cannot split a machine across policies.
• !Source must be powered on. CDP for powered-off machines is not supported.
• !Maximum 50 disks per workload in a CDP policy.
• !4K native sector disks are not supported.
• !If you resize a disk after the CDP policy starts, VBR destroys all existing restore points for that disk and restarts initial synchronization from scratch.
• !Thick-provisioned target disks require double the disk space during initial synchronization. The extra allocation is released after sync completes.

---

Step 1 - Install the CDP Agent and Volume Filter Driver

The agent and driver deploy through the VBR Protection Group mechanism. You do not push them manually. VBR manages installation through the same discovery and agent lifecycle infrastructure used for Veeam Agents.

1. 1 Open the VBR console. Navigate to Inventory > Physical Infrastructure. Right-click Physical Infrastructure and select Add Protection Group.
2. 2 Select the scope type. For Universal CDP you will typically use Individual computers or Microsoft Active Directory objects. CSV file import works for bulk adds. Click through to the Computers step and add your source machines by IP, DNS name, or AD object.
3. 3 At the Options step, check Install CDP agent. This enables both the Veeam CDP Agent Service and the Veeam CDP Volume Filter Driver. Check Perform reboot automatically if your maintenance window allows it. The driver will not activate without a reboot.
4. 4 Finish the wizard. VBR will scan the machines, push the agent and driver, and reboot if you allowed it. Monitor progress in the Activity pane.
5. 5 Confirm the reboot completed on all source machines. Do not proceed to policy creation until every source machine has rebooted and the driver is confirmed active.

---

Step 2 - Install the I/O Filter on the Target vSphere Cluster

The target vSphere cluster needs the Veeam I/O filter installed before any CDP policy can run. If you have already used native CDP for vSphere on this cluster, the filter is already there - skip this step and verify the version is current.

1. 1 In the VBR console, navigate to Backup Infrastructure > Managed Servers. Locate the vCenter server that manages your target cluster.
2. 2 Right-click the vCenter entry and select Manage I/O Filters. The I/O Filter Management wizard opens.
3. 3 Select the target cluster. Ensure the checkbox is checked next to every cluster where the filter must be present. Finish the wizard. VBR requests vCenter to install the filter on all hosts in the selected clusters.
4. 4 The filter installs automatically on all ESXi hosts in the cluster, including hosts added to the cluster later. New hosts added after initial filter deployment require you to re-run the I/O Filter Management wizard.

---

Step 3 - Add and Configure CDP Proxies

CDP proxies are separate from your regular backup proxies. They are added as managed servers and then assigned the CDP proxy role. You need at minimum one source proxy and one target proxy.

1. 1 Navigate to Backup Infrastructure > Backup Proxies. Right-click in the pane and select Add VMware CDP proxy (for native vSphere source) or Add CDP proxy (for Universal CDP).
2. 2 Select the server to assign the CDP proxy role. The server must already be added as a managed server in VBR. If it is not, add it first via Managed Servers > Add Server.
3. 3 Assign the role. VBR deploys the Veeam CDP Proxy Service on the target server. The deployment takes seconds for existing managed servers.
4. 4 Repeat for your target-side proxy. Label or document which proxies are source-side and which are target-side. While VBR can auto-select proxies, explicit assignment in the policy wizard gives you deterministic placement.

Proxy Sizing

RAM is the primary constraint. Each processed disk needs at least 1 MB of proxy RAM. A proxy with 32 GB RAM allocates approximately 24 GB to CDP data (8 GB reserved for OS), which can sustain roughly 24,000 concurrent 1 MB disk operations before spilling to cache. For high-write databases or large disk counts, right-size accordingly and add proxies to distribute load.

For physical proxy servers, fast network connectivity between the proxy and the ESXi hosts is critical. For virtual proxies, co-locate the source proxy on the same cluster as the source workloads and the target proxy on the same cluster as the replicas.

---

Step 4 - Create the Universal CDP Policy

With the agent deployed, I/O filter installed, and proxies added, you can create the policy. Every configuration decision here directly affects your RPO, storage consumption, and failover behavior.

1. 1 In the VBR console, go to Home > Jobs. Click CDP Policy and select Universal CDP.
2. 2 Name step: Give the policy a descriptive name. If you want network remapping (useful when production and DR networks differ), check Network remapping here - it adds the Network step to the wizard. You cannot add this later without recreating the policy.
3. 3 Machines step: Click Add and select workloads or protection groups. You can add individual machines or entire protection groups. Each machine can belong to only one CDP policy - VBR will warn you if you try to add a machine that is already covered by another policy.
4. 4 Destination step: Select the target host or cluster. Click Choose and select a vSphere host or cluster that has the I/O filter installed. In the datastore section, choose the target datastore for replica disks. Note: once the policy runs for the first time you cannot change the target host. Plan carefully.
5. 5 Policy Settings step: Set the replica name suffix. This suffix is appended to the source workload name to form the replica VM name. The suffix must be unique across replicas on the target host. Duplicates will cause the first policy run to fail.
6. 6 Schedule step: Configure RPO, short-term retention, and long-term retention. See the RPO Tuning section below before committing values here.
7. 7 Data Transfer step: Configure proxy selection. Automatic proxy selection is the default and generally works well for smaller deployments. For larger deployments or when you need deterministic proxy placement, switch to manual and assign source and target proxies explicitly.
8. 8 Finish and enable the policy. VBR will start the initial synchronization - a full disk copy of each source workload to the target replica. This is the heaviest network phase. Plan it for off-peak hours for large machines.

---

RPO Tuning and Retention Planning

The RPO setting in the policy is not just a target - it is the interval at which the source proxy commits short-term restore points to the target. Tighter RPO means more restore points per unit of time, higher proxy RAM pressure, more network traffic, and more IOPS on the target datastore.

RPO Guidance

Short-Term Retention

Short-term retention is defined in hours, up to the 168-hour maximum. How much retention you can hold depends on the write rate of the source and the available space on the target datastore. A VM writing 500 MB/hour with 24-hour short-term retention needs roughly 12 GB of target datastore space for the journal, plus the replica disk size. High-write databases can generate significantly more journal data per hour.

Long-Term Retention

Long-term restore points are managed separately from the journal. Schedule them via the Long-term Retention section in the policy wizard. You can schedule crash-consistent points on a time-of-day grid. Each scheduled point is stored as a separate restore point on the target datastore. The 95 points-per-disk ceiling is a hard limit enforced by VBR - exceeding it requires reducing retention count or increasing the schedule interval to stay under it.

---

Failing Over and Failing Back

The replica is in a ready-to-start state at all times. Failover is not a lengthy restore operation - it is a powered-off VM that you start on the target cluster, pointing at the last committed restore point or any point in the short-term retention window.

Initiating Failover

1. 1 In the VBR console, go to Home > Replicas. Locate the replica for the affected workload. Right-click and select Failover Now.
2. 2 Select the restore point. You can choose the most recent short-term point or scroll the timeline to a specific point in the short-term retention window. For corruption or ransomware scenarios, select a point prior to the event.
3. 3 Confirm. VBR powers on the replica. Network remapping (if configured) applies the DR network mappings. The replica VM is now live and serving as the production workload.

Failback

Once the source workload is repaired, you initiate failback from VBR. VBR calculates the changes that occurred on the replica during the failover period and ships them back to the source. After the reverse-replication completes, you commit the failback to switch operations back to the original source machine. If the source cannot be recovered at all, you can perform a permanent failover - this promotes the replica to the permanent production VM and removes the source association.

---

Gotchas and Common Failure Modes

These are the issues most likely to surface in a first or second deployment. Document them for your team before the first production rollout.

• ! Driver not activated until reboot. The Volume Filter Driver on source workloads must have a reboot to activate. Policies will fail on initial sync if the driver is not active. Always confirm reboot completed before enabling policies.
• ! vCenter cannot resolve VBR hostname. I/O filter installation fails with a generic "Operation is not allowed in the current state" error. The fix is adding a static host entry to the vCenter appliance's /etc/hosts file.
• ! Duplicate replica suffix. If a replica with the specified name suffix already exists on the target cluster from a previous policy or manual deployment, the first policy run fails. Clean up orphaned replicas before policy creation.
• ! Thick provisioned targets need double space during sync. During initial synchronization, thick-provisioned target disks require 2x the disk capacity. Space is released after sync completes but you must have the headroom available up front.
• ! Disk resize resets the entire replica. Resizing a source disk mid-protection destroys all existing restore points for that disk and restarts from initial synchronization. This is non-negotiable behavior - plan disk sizing before enabling CDP.
• ! I/O filter upgrade after ESXi host upgrade. If you upgrade ESXi host versions, the I/O filter must be upgraded at the same time or immediately after. Partially upgraded clusters block new CDP policy additions and failback commits.
• ! 400-policy cap per backup server. v13 raises the Universal CDP policy limit to 400 (up from 100 in v12 for native CDP). Plan VBR server scaling for large environments before hitting this ceiling.
• ! Network under 100 Mbps will fail in production. Continuous replication of write-active machines on a slow link creates gaps in the restore point chain. The docs state 100 Mbps as a minimum and proven performance on 10 Gbps with MTU 9000. Take this seriously for branch-to-DR scenarios.
• ! Encryption of transaction log files not supported. CDP transaction log files holding incremental changes for disks cannot be encrypted. If encryption is a compliance requirement, understand this limitation before committing to CDP as your sole protection method.

---

Monitoring CDP Policy Health

CDP policies are continuous processes - they do not have a pass/fail session model like backup jobs. Monitoring is ongoing.

In the VBR console, the Home > Replicas view shows the current state of all CDP replicas and the last committed restore point timestamp. A growing gap between the last restore point and the current time indicates a problem - either a proxy is under pressure or a component has failed.

Enable RPO Reporting in the policy Schedule step. Set a warning threshold and an error threshold. When restore points are not committed within the warning window, the policy status turns yellow. At the error threshold it turns red and fires email notification if you have SMTP configured. This is the earliest signal for RPO degradation short of active monitoring of the Veeam ONE dashboards.

In Veeam ONE, the CDP-specific dashboards show restore point age, policy health, and proxy load. For environments running multiple CDP policies at scale, Veeam ONE is the right monitoring layer rather than the VBR console alone.

---