Continuous Data Protection

Scheduled backups copy data at fixed intervals. Anything changed between two runs is at risk of data loss if primary storage fails. CDP closes that gap: an agent or storage layer intercepts every write, whether it is a file save, a database transaction, an edit or a deletion, and records it to a separate, protected journal or replica at the moment it happens.

The result is a continuous record of the data's state, so a system can be rewound to any point in time, not only to the last scheduled backup. Two implementations are common. Block-level CDP captures every write at the disk or volume layer, whatever application produced it. It protects everything on the volume but has no knowledge of application state. Application-level CDP reads the database or application transaction log, so recovery follows the application's own logic and restores a specific transaction rather than a raw disk state.

Each change passes through the same short path. The steps are identical for files and databases; only the object being recorded differs.

1. 1

   Intercept

   The agent or storage layer sees the write as it reaches the disk.

2. 2

   Journal

   The change is written to a separate journal or replica, without overwriting the original data.

3. 3

   Timestamp

   The journal entry receives a time, so recovery can select an exact moment.

4. 4

   Rewind

   On recovery, the system replays the journal up to the chosen moment and stops there.

The practical difference is the recovery point objective (RPO): the amount of data at risk when something goes wrong. A nightly backup leaves up to a full day of work exposed. CDP reduces that exposure to the last few seconds.

Systems that capture changes every few minutes instead of at every write are marketed as near-CDP. They are a major improvement over scheduled backup, but their recovery points remain discrete. The table compares the four approaches:

CDP is a recovery control, not a preventive one. It does not stop an incident. It limits how much data the incident destroys.

Typical uses include:

• restoring a deleted file or a file overwritten by mistake
• rolling back a failed update or a bad configuration change
• recovering a database with minimal transaction loss
• rolling back to the moment before ransomware began encrypting files

Every write is recorded twice, once in production data and once in the journal, so continuous capture has real costs. These trade-offs decide where CDP is deployed.

Journal placement and its own protection become design decisions from the start.

The journal records everything that happened, including the damage. Data that was already wrong when it was written stays wrong at every recovery point, so CDP cannot repair a logic error in an application. It also helps only if someone can identify when to roll back to. In a slow corruption or a quiet intrusion, that is the hard part, and this is where file integrity monitoring earns its place.

The journal is sensitive too. It holds the same data as production, so it needs equivalent access control and encryption of data at rest. Where an attacker with administrative access is in scope, it also needs immutability. A journal that the same credentials used to encrypt production can delete protects nothing.

CDP is applied selectively, to systems where the tolerable data-loss window is measured in seconds: transactional databases, order and payment systems, and virtual machines running business-critical applications. Systems whose content changes rarely, or where a few hours of loss is acceptable, usually stay on snapshots and scheduled backup. The cost of continuous capture is not justified by the gain in recovery point there.

Start with the systems where losing an hour would hurt most, then check how far back their recovery actually reaches. CDP is one layer of data protection, alongside access control and detection, and it works only when the restore point has been tested.

Further reading: Mechanisms for ensuring the security of information systems.