Traditional data backup happens once every so often – once an hour, once a day, once a week, for example, depending on the recovery requirements associated with the data. It’s typically the recovery point objective or RPO that determines the frequency of the backup. If you cannot afford to lose more than the last 30 minutes’ worth of data, then your RPO will be 30 minutes and backups will happen at least every half an hour. Continuous replication on the other hand changes the model by backing up your data every time you make a change. But what does that do to RPO, disk space requirements and network capacity (assuming you’re backing up to storage in a different physical location)?
While continuous data replication may result in a higher number of transactions compared to conventional, periodic backups, it doesn’t necessarily use more disk space. By being smart about operating at byte or block level (rather like data deduplication for reducing total storage space), continuous data replication may do better than traditional backups that shift entire files backwards and forwards, especially when file versioning is being used. Journaling lets continuous replication restore earlier versions of files too, but without having to store umpteen different versions of them.
It’s the network bandwidth or throttling consideration that will affects the recovery point objective. No throttling and a sufficiently fast network will mean you’ll be able to get back the very latest version of your data whenever you want. Otherwise, bandwidth restrictions may be applied in such a way as to reduce consumption of network resources down to a level that is still compatible with the desired RPO. The continuous data replication may then become ‘near continuous’, in which snapshots of the system are recorded as backups, rather than every incremental change that that is made. So whether or not you still need to factor in RPO will depend on how much bandwidth you’re prepared to make available to your continuous replication.