Backup vs Replication vs Snapshot Explained (2026 UK Guide)

Why 'we have backups' doesn't mean 'we can recover'

The confusion usually isn't technical ignorance — it's that a nightly job, a replicated VM, and a storage snapshot all look like 'coverage' on a dashboard. Each one produces a copy of data somewhere else. But a copy that faithfully mirrors corruption is not a recovery mechanism; it's just corruption with a second address.

At-Bay's analysis of policyholder incidents found that 92% of businesses had backup solutions in place, yet 31% still failed to restore data during a ransomware attack, while 63% did successfully restore. Having a backup process and being able to recover from it turned out to be two different outcomes for roughly a third of organisations studied — which is the entire premise of this article.

Backup, replication and snapshot: three different jobs

A backup is a point-in-time copy stored for later recovery, and it's specifically designed to retain multiple versions over time. That version history is precisely what lets a backup recover data from before deletion, corruption or a ransomware encryption event took place, according to Eon's comparison of the two approaches.

Replication works differently: it continuously syncs changes to a standby copy to keep data available for failover, rather than preserving history. Eon frames the distinction cleanly — a snapshot is a point-in-time copy used for recovery, while a replica is a continuously updated copy of live data used for availability.

A snapshot sits closer to replication in behaviour than to backup. Bacula Systems notes that storage snapshots are useful for point-in-time recovery, but they are not backups in the true sense because they usually remain on the same system as production data — sharing the same attack surface.

• •Backup: point-in-time, versioned, stored separately for recovery
• •Replication: continuous sync, no version history, built for availability
• •Snapshot: point-in-time, usually same-system, fast but not independently trusted

The comparison: RPO, RTO and what actually gets protected

Trilio's figures put this in concrete terms. Typical backup RPO runs from hours to days depending on backup frequency, and typical backup RTO also runs hours to days depending on data size. Replication is far tighter on both metrics: typical replication RPO is seconds to minutes because it syncs continuously, and typical RTO is minutes because failover is near-instant. These are stated as typical ranges rather than guaranteed SLAs, so they should be treated as planning inputs, not contractual promises.

That gap explains why replication feels like the superior technology on paper — until you need to recover from something replication itself copied faithfully. If your priority is minimising downtime after a hardware or site failure, replication's speed is genuinely valuable. If your priority is recovering clean data after corruption or malicious deletion, backup's version history is the only one of the three built for that job. Before sizing either, it helps to understand Recovery Time Objective (RTO) and Recovery Point Objective (RPO) as separate, non-interchangeable targets.

Snapshots occupy a narrower niche: fast, local, point-in-time rollback — useful for recovering from an accidental delete or a bad configuration change within the retention window, but not a substitute for either of the other two.

Why replication and snapshots fail exactly when you need them most

The failure mode is consistent across every source in this space: replication and snapshots don't distinguish good writes from bad ones. Eon is explicit that replication copies deletions, corruption and ransomware encryptions as well as normal changes, so it does not stop bad data from spreading to replicas. When malware encrypts production data, replication carries that encrypted data to every replica, and recovery then depends entirely on a separate, clean backup.

Computer Weekly describes the same mechanism for snapshots: a snapshot records the live state of a system to another location, so ransomware on the primary system can also be copied to the snapshot target. It goes further, noting that conventional backup systems face the same risk of copying compromised files into the backup library — which is exactly why immutability and isolation matter more than the label 'backup' on its own. This is the same principle behind why RAID is not a substitute for a true backup: redundancy and copying are not recovery guarantees.

The numbers on attacker behaviour reinforce this. Eon cites Sophos research finding that attackers attempted to compromise backups in 94% of ransomware incidents and succeeded 57% of the time. Separately, Veeam's research found that 93% of cyber-attacks target backup repositories specifically, and 39% of those repositories were completely lost during the attack. These are two different studies measuring different populations, but they point the same direction: backup infrastructure is now a primary target, not an afterthought.

The 2026 baseline: immutable copies and the 3-2-1-1-0 rule

The classic the fundamental 3-2-1 backup rule has been extended for this threat landscape. Bacula Systems describes the modernised version, 3-2-1-1-0, as three copies of data, on two different media types, with one copy off-site, one copy immutable or offline, and zero errors — verified through regular recovery testing.

The extra '1' matters most against ransomware: an immutable or offline copy cannot be altered or deleted even by an attacker with valid credentials, which directly addresses the Veeam finding that 39% of backup repositories were completely lost during attacks. Getting comfortable with the concept of immutable backups is now a baseline design requirement, not an optional upgrade.

Continuous Data Protection (CDP) sits between snapshot and replication in behaviour: rather than syncing at intervals, it journals writes continuously, allowing recovery to a much finer-grained point in time than a scheduled snapshot or backup job would allow. The trade-off is complexity and infrastructure overhead — CDP demands more from storage and networking than a scheduled snapshot, and like replication, it can still propagate corrupted writes unless paired with an isolated, versioned backup layer.

On tooling, organisations increasingly weigh proprietary platforms against options that preserve portable, open backup formats specifically to avoid being locked into one vendor's recovery path — a reasonable precaution when the backup layer itself is the thing under attack.

Cost, storage and bandwidth trade-offs for UK businesses

Each approach loads cost onto a different part of the infrastructure. Replication needs an always-on standby system and continuous bandwidth to keep it in sync — cost that's incurred whether or not you ever need to fail over. Snapshots consume space on the primary storage array itself, and that space is only reclaimed as older snapshots age out of the retention window. Backups, by contrast, can sit on cheaper object or archive-tier storage, but retaining multiple historical versions increases the total storage footprint compared with a single replica.

At-Bay's recovery-rate data is a useful proxy for why architecture choice matters more than raw storage cost: cloud backup architectures had an 80% recovery rate, compared with 55% for offsite and 56% for onsite configurations. A cheaper onsite setup that recovers half the time isn't actually cheaper once the cost of a failed restoration is counted.

Beyond storage economics, UK organisations have a governance reason to prioritise the backup layer over the cheapest option: recovery capability underpins data integrity obligations under UK GDPR, and immutable, tested backups — separated from production credentials — are the clearest way to demonstrate that data can still be restored intact after encryption, corruption, or malicious deletion, which is increasingly how broader UK operational-resilience expectations are framed. Seen this way, the buying decision is less about the price per gigabyte of storage and more about whether the control can prove recoverability under audit, which is why the testing and verification step — the 'zero errors' element of 3-2-1-1-0 — carries as much governance weight as the immutable copy itself.

Before committing budget to any one layer, it's worth running the numbers properly — you can size your backup and disaster recovery solutions against your actual RPO/RTO targets, and check what an hour of downtime would genuinely cost your organisation.

A worked example: layering all three for a UK SME

Consider a typical mid-sized UK business running a production database and file server. Replication to a standby site handles infrastructure failure: if the primary array or site goes down, failover completes in minutes, in line with Trilio's typical replication RTO. Storage snapshots taken through the day give staff a fast, local rollback option for accidental deletions or bad changes, without needing a full restore.

Sitting alongside both is a scheduled, application-consistent backup, retained with an immutable copy in cloud object storage. This is the layer that survives what replication and snapshots cannot: if ransomware encrypts production data, the replica and the day's snapshots are compromised along with it, but the immutable backup copy — isolated from production credentials — remains recoverable, consistent with Eon's point that recovery in that scenario depends on a separate, clean backup.

Mapped against 3-2-1-1-0: production, the replica, and the backup form the three copies; the primary array plus cloud object storage form the two media types; the cloud backup satisfies the off-site requirement; the immutable retention policy satisfies the '1' immutable copy; and scheduled test restores deliver the 'zero errors' verification. None of the three layers is optional — each one covers a failure mode the others don't.

Choosing your strategy: a decision framework

Start from the failure you're most worried about, not the technology you already have.

• •Hardware or site failure that must not interrupt service → replication, sized for minutes-level RTO
• •Accidental deletion or a bad config change within the day → snapshot, for fast local rollback
• •Ransomware, corruption or malicious deletion by a compromised account → immutable, off-site, tested backup — this is non-negotiable and the only one of the three built for it
• •Constrained budget → prioritise the backup layer first; At-Bay found backups successfully restored data in 63% of ransomware cases, versus replication's near-zero value against corrupted data
• •Any layer you rely on → test it. Veeam's finding that 39% of backup repositories were completely lost during attacks is a strong argument for isolated credentials and regular recovery drills, not just isolated storage

Sources

Every figure in this article traces to the sources below.

• •Eon — replication vs backup mechanics and failure modes
• •Computer Weekly — limits and risks of backup/snapshot as ransomware protection
• •At-Bay — ransomware backup recovery rates by architecture
• •Veeam — attacks targeting backup repositories
• •Trilio — typical RPO/RTO ranges for backup vs replication
• •Bacula Systems — the 3-2-1-1-0 rule and snapshot limitations