Snapshots Are Not Backups: Why Your Recovery Copy Lives Inside the Blast Radius

The difference between a snapshot and a backup is not a matter of vocabulary. It is whether your recovery copy lives inside the same failure domain as the thing it is supposed to rescue — and for most teams, it does. That single architectural fact is why so many recovery plans pass every audit and still fail on the day they are needed.

Both operations produce something that looks like a saved copy. Both can be restored. Both appear in the same console, often with similar names. But they answer different questions, and only one of them answers the question that actually gets asked at three in the morning.

A snapshot answers: can I undo the change I am about to make? A backup answers: can I rebuild this service after it is gone? Teams that treat the first as the second are not under-protected by a small margin. They are unprotected against an entire class of failure that no amount of snapshotting frequency will cover.

Two Operations That Only Look Alike

The confusion is understandable, because the surface behaviour is nearly identical. You run a command, the system reports success, and a restore point appears. The divergence is in what that restore point is coupled to.

Reading the table from the top, the first four rows describe differences of degree. The last four describe differences of kind. A snapshot and a backup are not fast and slow versions of the same safety net; they are fitted to different accidents.

What a Snapshot Actually Captures

A snapshot is a point-in-time representation of a disk, volume, or virtual machine. Restoring it returns the infrastructure to the state recorded at that moment. That is genuinely useful, and it is why snapshots exist.

Two properties of that mechanism deserve attention, because both are routinely misread as guarantees.

A snapshot captures the state as it was, including the parts that are wrong. If a file was already deleted, encrypted, or silently corrupted when the snapshot was taken, the restore point contains the identical problem. Snapshots do not know what a healthy system looks like. They preserve whatever existed at the moment of capture, and if an attacker spent three weeks inside your environment before triggering, the three weeks of snapshots they permit to exist all contain their work.

Most storage-layer snapshots are crash-consistent rather than transaction-aware. The snapshot may be taken while a database is mid-write. Restoring it is equivalent to recovering from an unexpected power loss: the engine will need to replay or roll back its log, and depending on what was in flight, that recovery is not guaranteed to land on a clean state. An operating system handles this routinely. A busy database under load is a less forgiving case.

Neither property makes snapshots a bad tool. Both make them unsuitable as the only tool, because the failure modes they cannot cover are precisely the ones that destroy businesses rather than annoy them.

The Storage Location Is the Entire Argument

Here is the part that decides the outcome, and it is a question of topology rather than of technology.

By default, snapshots are kept inside the same account, the same platform, and the same management boundary as the source system. That default is convenient, and it is also the reason a snapshot cannot be your last line of defence. If an attacker obtains credentials that reach the production environment, those same credentials typically reach the snapshots, because the snapshot API and the production API sit behind the same authentication system.

The scale of that exposure is now well measured. Sophos's seventh annual State of Ransomware survey, published in July 2026 and based on 2,158 respondents across 17 countries, found that 79% of ransomware attacks began with an identity-based approach, with compromised credentials the root cause in 23% of cases. The practical consequence for anyone designing recovery is stated most clearly in the analyst commentary around that report: any recovery copy reachable with a credential is inside the blast radius by definition.

That reframes the question. The useful test is not "do I have snapshots" but "is there any credential that can reach both my production system and my recovery copy, and does that credential have permission to delete?" If the answer is yes, you have a speed bump, not a control. Immutability configured through the same console an attacker can log into does not survive contact with that attacker.

The mitigation is separation along axes an intruder cannot cross with one stolen identity: different credentials, restricted deletion permissions, a different account or provider, object lock in a governance mode that the backup service account itself cannot override, or a copy with no standing network path at all. The technical term for the last of these is offline. The commercial term is inconvenient. It is also the only version that has consistently survived a determined intrusion.

What Backups Provide That Snapshots Structurally Cannot

A backup is a recovery copy created on a schedule and retained across a retention window, deliberately placed so that it can outlive the failure of the thing it protects. Three capabilities follow from that definition, and none of them are available from a snapshot alone.

History, not a moment. Corruption and intrusion are frequently discovered long after they began. A snapshot from this morning is useless if the damage dates from last month. A retention policy that keeps daily copies for a fortnight and weekly copies for a quarter gives you a window wide enough to reach back past the origin of the problem. Snapshots are short and change-oriented by design; they are meant to be pruned, not accumulated.

A separate failure domain. A backup engineered correctly lives somewhere that an incident affecting production does not automatically reach — a different account, a different provider, a different region, or physical media. This is the difference between a copy that survives and a copy that is merely adjacent.

Granularity. Backups can be built at several layers, and choosing the right one is an engineering decision rather than a storage decision. Volume-level backups rebuild a whole machine. File-level backups let you recover a single directory. Logical database dumps are portable but slow on large datasets. Physical database backups restore faster but are tied to the engine and version. Transaction log or WAL archiving enables point-in-time recovery of a database and is the only method that reaches the RPO a transactional system usually needs.

Replication Is Not a Backup Either

The same mistake appears in a second form, and it is arguably more dangerous because the architecture looks sophisticated.

Replication copies changes from one location to another continuously. It is excellent for availability and it does nothing for recovery. If an operator deletes a table, replication faithfully deletes the replica. If ransomware encrypts the primary, the replica receives the encrypted blocks within seconds. Replication propagates the damage with low latency and high fidelity, which is the opposite of what a recovery copy is for.

High availability and recoverability are different properties with different designs. A replicated pair can deliver 99.95% uptime and still be unable to restore last Tuesday, because at no point did it retain last Tuesday.

The Rule That Has Not Been Improved On

The 3-2-1 rule originated in photography, proposed by Peter Krogh as a way to protect a photographer's archive. It transferred to IT because the logic is about copies and failure domains rather than about media.

Three copies of the data. Two different storage types or mechanisms. One copy held separately from the primary environment. Later formulations extend it with a fourth and fifth element — one copy immutable or offline, and zero errors verified on restore — which is a useful sharpening rather than a replacement.

Applied to this discussion, the rule explains the whole problem in one line. Snapshots frequently satisfy the first criterion and violate the third, which is the one that matters most. A disciplined small team with three genuinely separated copies is better protected than a large team with forty snapshots and one account.

RPO and RTO Decide the Architecture, Not the Budget

Two numbers should be written down before any tool is chosen, because they are the requirements the tooling exists to satisfy.

Recovery point objective (RPO) is how much recent data you can afford to lose, expressed as time. Recovery time objective (RTO) is how quickly the service must be running again. Both are business decisions that constrain engineering, not the other way round.

The trap is choosing the mechanism first and inferring the objectives afterwards. A snapshot strategy that keeps four hours of history imposes a four-hour RPO whether or not the business can tolerate it, and no one discovers the mismatch until the incident review.

A Successful Backup Job Proves Almost Nothing

This is the failure mode that hides longest, because every indicator is green.

A backup task that reports success has demonstrated that data moved from one location to another. It has not demonstrated that the result is complete, readable, or sufficient to rebuild the service. A restore test should confirm each of the following, and the list is longer than most teams expect:

• The correct recovery point can be located under pressure, by someone other than its author
• Encryption keys and credentials are themselves available — backups are frequently encrypted with keys stored only inside the environment that was lost
• Replacement infrastructure can actually be provisioned at the scale required
• The data restores without integrity errors, verified rather than assumed
• The application starts and completes its own consistency checks
• DNS, certificates, secrets, and network configuration are restored — data alone rarely rebuilds a service
• Critical user workflows function end to end, not merely the login screen
• Measured data loss meets the stated RPO
• Measured restore time meets the stated RTO

That last pair is the point of the exercise. An untested backup is a hypothesis, and the only evidence that transfers to a real incident is a restore you have actually performed at a representative scale, in an isolated environment, on a schedule.

What the Current Data Says About Who Recovers

The 2026 figures are more encouraging than the previous five years, with one important qualification.

Among organisations whose data was encrypted, 66% restored from backups — a rise of 12 percentage points year over year, and the first time in the survey's history that restoring from your own copies has overtaken paying a ransom, which stood at 48%. That is a genuine vindication of immutability, retention locks, and separated copies.

The qualification is in the same dataset. 56% of attacks still succeeded in encrypting data, up from 50%, and average recovery cost per incident rose 11% to $1.7 million excluding ransom. Prevention is losing ground while recovery is gaining it. And the gradient by organisation size is steep: only 34% of organisations with 100 to 250 employees stopped an attack before encryption, against 46% at firms with 3,001 to 5,000 employees.

For a small team, the honest reading is that recoverability is not a fallback layer sitting behind prevention. It is the primary control, because prevention fails more often than it succeeds. Scale is not available to buy, but discipline is.

A Layering Scheme That Fits a Small Team

None of this requires an enterprise data-protection platform. It requires four layers with clearly distinct jobs, and a willingness to keep them genuinely separate.

The fourth row is the one most often skipped and the one that wastes the most time during a real recovery. Infrastructure-as-code definitions, DNS records, TLS certificates, API keys, and environment configuration are frequently the difference between a restore that finishes and a service that runs. A recovery point that contains perfect data and no way to authenticate it is not a recovery.

Two operational habits make the scheme hold. Set the separation up front rather than during an incident, because the moment you need an off-site copy is the worst possible moment to be configuring one. And put a calendar reminder on the restore test, because the only backup you can rely on is the one you have restored.

Choosing Infrastructure With Data Protection in Mind

The architectural choices above are mostly platform-independent, but the platform determines how much of the separation you have to build yourself, and how the copy on the far side is paid for.

One practical detail worth planning before you provision anything: an off-site copy consumes outbound transfer every time it runs. On a metered plan that makes the backup design and the bandwidth budget the same conversation, and a retention policy chosen without accounting for it tends to be quietly reduced the first time an invoice arrives. The Hong Kong node plans on SurferCloud price outbound traffic in tiers of 1 to 4 TB alongside 30 Mbps bandwidth, which at least makes the ceiling visible rather than discovered — and the tier structure means the backup schedule and the plan size can be matched deliberately. The higher tiers list data backup and multiple data protection among their features, and the provision sits inside the region you are already serving from, which matters if the copy is there to cover a regional problem rather than a provider one.

One further consideration favours the lighter tiers for this specific job. A backup target does not need high CPU or large memory; it needs predictable storage, enough transfer allowance for the copies themselves, and a price that stays the same on renewal so a multi-year retention policy does not become an annual budget argument. The essential and starter configurations are structured that way, with renewal priced at the same rate as the initial term. Teams whose recovery copies need to sit closer to heavy compute, or who want the backup target to double as a rebuild target, are better served by the elastic compute range, where resources can be scaled after the workload is understood — and the cloud server overview sets out where the lightweight and elastic grades diverge.

Whichever route you take, the requirement is the same and it does not come from a product page: the recovery copy has to be somewhere that the failure cannot follow it. Everything else is provisioning.

FAQ

Is a snapshot a backup?
No. A snapshot is a point-in-time representation used to roll back recent changes. A backup is a scheduled copy retained across a window and stored so it survives the failure of the source. They cover different failure classes.

Can I rely on snapshots if I take them often?
Frequency does not fix the structural problem. Increasing snapshot frequency narrows the data loss window but does not remove the copy from the same failure domain, which is what matters in an account compromise or ransomware incident.

How long should I keep backups?
Long enough to reach back past the origin of the failure. Because corruption and intrusion are often discovered weeks after they begin, a common pattern is daily copies for a fortnight and weekly copies for a quarter, with longer retention where compliance requires it.

Is a replicated server a backup?
No. Replication copies changes as they happen, including deletions, corruption, and encryption. It improves availability and provides no historical recoverability.

Why do restore tests matter if the backup job succeeds?
Because a successful job proves data moved, not that it is usable. Only an actual restore confirms that the copy is complete, that keys and configuration are available, and that RPO and RTO are met.

What is the 3-2-1 rule?
Keep three copies of the data, on two different storage types, with one copy held separately from the primary environment. Extended versions add one immutable or offline copy and zero errors verified on restore.

Do I need both snapshots and backups?
If you deploy changes frequently and also need to survive data loss, yes. Snapshots handle fast rollback inside a change window; backups handle recovery from failures that a rollback cannot reach.

Summary

A snapshot and a backup are not two versions of the same safeguard. A snapshot reverses a change you decided to make; a backup recovers from a failure you did not choose. The first is a rollback tool and the second is a survival tool, and the reason the distinction costs teams their data is that snapshots are convenient enough to be mistaken for the second while structurally unable to perform the job.

Three things follow, and none of them require new spending. Test the separation rather than the existence: ask which credentials can reach both production and your recovery copy, and whether any of them can delete it. Write down RPO and RTO before selecting tooling, because those two numbers constrain the architecture and not the reverse. And schedule restore tests at representative scale, because a recovery capability you have never exercised is a hypothesis rather than a control.

Do those three things and the tooling question answers itself. Frequent snapshots for the changes you plan, retained backups for the failures you do not, and one copy somewhere the failure cannot follow it. That combination has survived every version of this problem so far, and no amount of storage-layer convenience has replaced it.