By Uniqcli Team
Continuous data protection (CDP) captures every change to a protected data set as it happens and records it in a time-ordered journal, so that the data can be restored to effectively any moment rather than to a fixed set of scheduled restore points. A conventional backup regime produces a handful of recovery points a day; CDP produces a continuum, and recovery becomes a question of which second to rewind to rather than which nightly job to restore from.
The reason to care is the recovery point objective — the amount of data an organization can afford to lose, measured in time. A nightly backup implies an RPO of up to twenty-four hours. Hourly snapshots imply an hour. CDP aims at seconds or less, which is the only answer that works for systems where an hour of lost transactions is not a recoverable position. The Storage Networking Industry Association's definition of the category is straightforward on this point: it is about capturing every write.
It is also the storage technology most frequently misdescribed in product literature, because a great many things marketed as CDP are snapshot schedules running frequently. That distinction is the difference between an RPO of seconds and an RPO of several minutes, and it is worth resolving before a comparison rather than after a recovery.
How continuous data protection works
The mechanism is a write splitter and a journal. Something in the write path — a hypervisor filter driver, an agent on the host, a controller inside the storage array, or a function of the replication appliance — intercepts each write as the application issues it, sends it to primary storage as normal, and simultaneously sends a copy to the protection system. There it is appended to a journal with a timestamp and, in application-aware implementations, a consistency marker.
Because the journal is an ordered record of every change rather than a set of full copies, recovery works by replay. To restore to a chosen moment, the system takes a base image and applies the journal entries up to that point, producing the exact state the volume was in. That is what makes any-point-in-time recovery possible, and it is why the journal's retention window — how far back the record extends before older entries are consolidated or discarded — is the single most important number in a CDP configuration.
Application consistency is the detail that decides whether a recovery is useful. A crash-consistent point looks to the application exactly as if the power failed at that instant: usually recoverable for a database with a transaction log, sometimes not for other software. Application-consistent points are coordinated with the application so that in-flight transactions are settled and buffers flushed, typically via the operating system's snapshot coordination framework or a database-specific hook. A good implementation tags consistent points inside the continuous journal, so an operator can rewind to any second and also see which seconds are known-good.
True CDP versus near-CDP
True CDP records every write. There is no interval, no schedule and no gap, and the theoretical recovery point objective is effectively zero — whatever the last acknowledged write was. Near-CDP takes very frequent block-level snapshots or replication cycles instead: the interval is short, but it is an interval, and the achievable RPO is whatever that interval is. Published figures for near-CDP products commonly land somewhere between thirty seconds and fifteen minutes.
Both are legitimate technologies and only one of them is the thing the acronym describes. The industry has been loose about this for years, and the practical consequence is that two products presented as CDP can differ by three orders of magnitude in the amount of data a failure loses. The question that resolves it is not 'is this CDP' but 'if the array fails right now, how many seconds of writes are unrecoverable, and is that a guarantee or an average'.
Two more questions belong in the same conversation. How far back does the journal reach — a system with a four-hour window cannot recover from anything discovered on Monday that happened on Friday. And what is the recovery granularity within that window: some products can restore to any write, others to the nearest consistency marker, which may be a minute or more apart even when the journal itself is continuous.
What CDP does to RPO — and what it does not do to RTO
Recovery point objective and recovery time objective are separate numbers that answer separate questions: how much data may be lost, and how long the restoration may take. CDP is an RPO technology. It collapses potential data loss toward zero, and by itself it makes no promise at all about how quickly a system will be running again.
In practice the two often improve together, because a system that holds a continuously replicated copy at a second site can frequently fail over to that copy rather than restoring from tape or object storage. But the mechanism that delivers a short RTO is the standby infrastructure and the failover process, not the journal. A CDP deployment with no capacity to run the workload anywhere else has an excellent recovery point and an RTO measured in however long it takes to procure and provision replacement hardware.
The corollary is that CDP is worth buying against a tiering exercise rather than fleet-wide. Rank workloads by what an hour of lost data actually costs and by how long the business can be without them, and the answers will differ sharply across the estate. A transactional system where every record is a customer commitment justifies a journal; a file share of reference documents rarely does, and an archive almost never does.
What it costs: journal capacity, bandwidth and latency
The journal is additional storage sized by change rate multiplied by retention window, not by the size of the protected data set. A ten-terabyte volume with a modest daily change rate can be journaled cheaply; a busy database that rewrites a large fraction of itself daily will generate a journal disproportionate to its footprint. The measurement to take before sizing anything is the actual change rate over a full business cycle including month-end, because peak change rate, not average, is what overruns a window.
Replication bandwidth follows the same logic and is the most commonly underestimated line. A link sized to the average write rate will fall behind during peaks, and a journal that falls behind is a recovery point objective that quietly degrades — often without a visible alarm until someone checks the lag figure. Size the link against sustained peak write throughput, confirm that the product reports replication lag as a monitored metric, and alert on it.
Then there is the write path itself. Intercepting and forwarding every write adds work, and how much depends on the implementation and on whether the journal write is acknowledged synchronously. Synchronous journaling to a remote site adds the round-trip time to every write, which is why synchronous configurations are usually confined to metropolitan distances. Asynchronous journaling removes that latency and reintroduces a small window of potential loss — which is the trade-off, stated plainly, that most deployments actually make.
CDP is not a backup, and it is not immutable by default
A journal that faithfully records every write also faithfully records malicious ones. Ransomware encrypting a volume produces writes, and those writes replicate exactly as legitimate ones do. What CDP offers against that threat is the rewind: the ability to return to the second before encryption began, which is genuinely valuable and considerably better than losing a day. What it does not offer is immunity, and the protection only holds under two conditions.
The first is that the journal window must outlast detection. If encryption began on Thursday, was noticed on Monday, and the journal reaches back four hours, the rewind target no longer exists. Dwell time in real incidents is routinely longer than the retention windows people configure, which is an argument for pairing a short-window journal with longer-retention copies rather than treating the journal as the whole strategy.
The second is that the journal must be out of reach of whoever compromised the environment. Attackers target backup infrastructure deliberately, and a protection system administered with the same credentials as the systems it protects can be deleted by anyone who obtains them. This is where CDP meets immutable and air-gapped storage: object-lock or write-once retention on the longer-term copies, separate administrative credentials for the protection platform, and a copy that cannot be deleted from the production environment at all. The 3-2-1 principle — three copies, two media types, one off-site or offline — is not superseded by continuous journaling; the journal is one of the copies. NIST's contingency-planning guidance in SP 800-34 remains the reference most public-sector programs write their plans against.
Where CDP fits, and where snapshots are enough
The strong cases share a shape: high transaction value, high change rate, and low tolerance for lost records. Order-entry and payment systems, case-management and clinical systems, claims processing, dispatch and other operational systems whose records are commitments to somebody. In those environments the cost of the journal is small against the cost of re-creating an hour of transactions, assuming they can be re-created at all.
The weak cases are equally recognizable. File shares of documents that change slowly, virtual desktop images rebuilt from a template, development and test environments, and archives with defined retention are all served adequately by scheduled snapshots and conventional backup, at a fraction of the storage and bandwidth. Applying CDP uniformly across an estate mostly buys journal capacity for data nobody would have missed.
Practically, the technology usually arrives as a feature of something else — a hypervisor-level replication product, a storage array's own replication engine, or a data-protection platform's continuous tier — rather than as a standalone purchase. That means the evaluation is often about which existing platform to extend, and the questions are consistent whichever route it takes: what is the guaranteed recovery point rather than the typical one, how long is the journal window, what is the recovery granularity, how is replication lag monitored, whether recovery points can be tested without disturbing production, and who can delete the journal.
Key takeaways
- Continuous data protection journals every write with a timestamp, so recovery is a rewind to a chosen moment rather than a restore from the last scheduled job.
- True CDP captures every write and targets a recovery point objective near zero; near-CDP takes very frequent snapshots and typically lands between thirty seconds and fifteen minutes.
- It is an RPO technology, not an RTO one — short restoration times come from standby infrastructure and a rehearsed failover process, not from the journal itself.
- Journal capacity is sized by change rate times retention window, and replication links must be sized to peak write throughput; a link sized to the average degrades the RPO silently during peaks.
- Against ransomware the value is rewinding to the second before encryption, which only works if the journal window outlasts detection and the journal cannot be deleted with production credentials.
- Tier it per workload: transactional systems where lost records are lost commitments justify a journal, while file shares, rebuildable images and archives are adequately served by snapshots.
Shop it at Uniqcli
Frequently asked
- What is the difference between CDP and a backup?
- A backup produces discrete copies on a schedule, so recovery lands on one of a fixed set of points — last night, last week, last month — and anything written since the most recent one is lost. Continuous data protection records every write into a time-ordered journal, so recovery can target effectively any moment within the journal's retention window. They are complementary rather than competing: journals are typically short-window and live close to production, while backups provide the long retention, the second media type and the off-site or offline copy that a journal does not supply on its own.
- What recovery point objective can CDP actually achieve?
- True CDP, which captures every write, targets an RPO of effectively zero — the worst case is the last write not yet acknowledged by the journal. Near-CDP products, which take very frequent snapshots or replication cycles rather than intercepting each write, achieve whatever their interval is, commonly quoted between thirty seconds and fifteen minutes. Because both are marketed under the same name, the useful question during evaluation is not which label a product uses but how many seconds of writes are unrecoverable if the primary fails right now, and whether that figure is guaranteed or typical.
- Does CDP protect against ransomware?
- Partially, and the qualification matters. Encryption produces writes, and a journal records those writes like any others — so the protection is not prevention, it is the ability to rewind to the second before encryption started. That works only if two conditions hold. The journal window has to reach back further than the time it took to detect the attack, which is frequently longer than the windows people configure. And the journal has to be outside the attacker's reach, which means separate administrative credentials and, for the longer-retention copies, immutable or air-gapped storage that production credentials cannot delete.
- How much extra storage does CDP need?
- It scales with change rate and retention window rather than with the size of the protected data. A large but slow-changing volume journals cheaply; a busy database that rewrites much of itself each day produces a journal out of proportion to its footprint. Measure the actual change rate across a full business cycle including month-end and any batch processing before sizing, and size against peak rather than average — the same applies to replication bandwidth, where a link sized to the average silently degrades the recovery point during busy periods.
- Is near-CDP good enough?
- For most workloads, yes. An RPO of a few minutes is a large improvement on nightly backup and costs considerably less than write-level journaling in storage, bandwidth and write-path overhead. The workloads that genuinely need true CDP are the ones where lost records cannot be reconstructed — transactions that represent commitments to customers, clinical or case records, dispatch and payment systems. The right approach is to tier by workload rather than to standardize, and to state the required RPO per tier before evaluating products against it.
- Does CDP replace snapshots and replication?
- No, and it usually arrives as an extension of them. Snapshots remain useful for fast local rollback and for the application-consistent points that make a recovery predictable, and replication remains what gets a usable copy to a second site. Continuous journaling adds the granularity between those points. In most estates the technology is a tier within an existing hypervisor-, array- or platform-level data protection product rather than a separate purchase, so the practical decision is which of those to extend and which workloads to place in the continuous tier.
Keep reading