Does continuous backup protect you against ransomware?

What is continuous backup, and how is it different from a nightly backup?

Continuous backup, often called continuous data protection (CDP), records every change shortly after it's written, instead of taking one copy at a fixed time. A nightly backup gives you one restore point a day; continuous backup gives you many.

The difference shows up in your recovery point objective. NIST defines the recovery point objective as "the point in time to which data must be recovered after an outage". In plain terms, RPO is how much work you can afford to lose. With a nightly backup at 22:00, a ransomware attack at 15:00 the next day can wipe out 17 hours of invoices, drawings and email.

Frequency is one layer of a backup design, not the whole design. On our backup as a service page we explain the other layers that decide whether a restore works after an attack.

Why does backup frequency matter in a ransomware attack?

Because attackers choose their moment. The longer the gap since your last good copy, the more work you lose, and ransomware groups tend to strike when you're least ready to respond.

The FBI and CISA warned in a joint advisory on ransomware over holidays and weekends that attackers see those periods as attractive because "network defenders and IT support of victim organizations are at limited capacity for an extended time". The advisory cites attacks on Mother's Day, Memorial Day and the Fourth of July 2021, including the Kaseya attack that hit multiple managed service providers.

Timing isn't the only tactic. In Sophos' 2024 survey of organisations hit by ransomware, 94% said the criminals tried to compromise their backups, and 57% of those attempts succeeded. Organisations with compromised backups reported median recovery costs of $3 million, against $375,000 for those whose backups survived.

Ransomware is still the biggest threat in Europe. The ENISA Threat Landscape 2025 calls it "the most impactful threat in the EU". So the question isn't only how often you back up, but whether those copies survive contact with the attacker.

Can continuous backup make ransomware recovery harder?

Yes, if it's set up as replication without protected history. A system that copies every change within minutes will copy encrypted files within minutes as well.

Microsoft's documentation for Azure Site Recovery is a clear example of continuous replication. Disk writes are "immediately transferred", crash-consistent recovery points are created every five minutes, and the default recovery point retention is one day. That design is built for disaster recovery after an outage. If an attacker has been active for longer than your retention window, every recovery point may already contain their work.

The dwell time problem

Attackers rarely encrypt on day one. Mandiant's M-Trends 2026 report puts global median dwell time, the time an intruder spends inside before being found, at 14 days. Mandiant also describes attackers mapping storage locations "before systematically deleting backup objects from cloud storage and local systems".

MITRE ATT&CK tracks this behaviour as T1490 Inhibit System Recovery: deleting shadow copies and backup catalogues, encrypting virtual machine snapshots and disabling versioning. A continuous backup with a two-day history doesn't help if the last clean state is three weeks old.

• Keep history longer than likely dwell time: weeks of restore points, not hours.
• Protect that history: an attacker with admin access must not be able to shorten retention or delete restore points.
• Know which point is clean: malware scanning and restore tests tell you where to roll back to. Our article on anomaly detection in backups covers how MSPs spot the moment encryption started.

What does a ransomware-resistant backup need besides frequency?

Immutability, isolation, separate access and proof that restores work. Frequency decides how much you lose; these four decide whether you can recover at all.

The UK National Cyber Security Centre's principles for ransomware-resistant cloud backups describe what that looks like. Backups should resist deletion and editing, customers should be able to restore from versions taken before the corruption, and alerts should fire when "significant changes are made, or privileged actions are attempted".

1. Immutable copies. Write-once storage, such as Object Lock, prevents backups from being deleted or overwritten for a set period. In AWS's compliance mode, not even the root user can shorten the retention period.
2. An air-gapped copy. One copy sits outside the reach of your production credentials and network. This is the extra "1" in the 3-2-1-1-0 rule.
3. Separate, MFA-protected admin access. Compromising your domain admin shouldn't give anyone control over the backups.
4. Verified restores. The "0" in 3-2-1-1-0 stands for zero errors after a verified restore.

That's how we build our service. Backups are stored only in our own Tier III data centres in the Netherlands and Germany, kept immutable with Object Lock plus an air-gapped copy. Every backup job is checked automatically, backups are scanned for malware, admin actions require MFA and the platform is monitored 24/7. If you need systems running again fast, we restore critical workloads on a 4-hour SLA, and instant VM boot brings servers up in an isolated recovery environment on a separate, clean network.

How often should you back up each system?

As often as the cost of lost work justifies, system by system. A shared drive full of daily design work needs a shorter RPO than an archive that changes once a month.

1. List your systems and who works in them: mailboxes, file shares, databases, line-of-business applications, laptops.
2. Estimate what an hour of lost work costs for each one: staff time to redo it, missed orders, contractual penalties. Our guide to the cost of downtime walks through the calculation.
3. Set an RPO and an RTO (recovery time objective, how quickly you need it back) for each system. Our RTO and RPO explainer helps you set realistic targets.
4. Match the method to the target. Busy file servers and databases may justify several jobs a day or continuous protection; stable systems can stay on a daily schedule.
5. Set retention longer than likely dwell time, so you can step back weeks, not only hours.
6. Test against the target. Restore a real file and a real server, and time it. See how to verify your backup works.

What to do next

Continuous backup is a useful way to shrink the amount of work a ransomware attack can cost you. On its own, it isn't ransomware protection. Pair the right frequency for each system with immutable, isolated copies, a history longer than an attacker's dwell time, and regular restore tests.

If your organisation falls under NIS2, this is a legal requirement as well as good practice. Article 21(2)(c) of the NIS2 Directive (EU) 2022/2555 lists "business continuity, such as backup management and disaster recovery, and crisis management" among the measures you must take. See how the layers fit together on our backup as a service page.

Want to see how quickly a clean restore point comes back from an EU data centre? Book a free 15-minute demo and talk to a person in Dutch, German or English.

This article is information, not legal advice.