Backups and snapshots are not the same thing

Snapshots and backups are frequently treated as interchangeable, and the distinction only becomes visible at the worst possible moment. They protect against different things, and a strategy built on one while believing it provides the other is a strategy with a gap in it.

What each actually is

A snapshot is a point-in-time image of a storage volume, usually stored within the same platform and often in the same region. Creating one is fast and cheap because it stores only the blocks that have changed since the last one. Restoring is fast because the data is right there.

A backup is an independent copy of data, ideally stored somewhere separate from the original, in a format that can be restored without the original system existing.

The critical difference is dependency. A snapshot generally depends on the platform, the account and often the region it was taken in. A proper backup does not.

What snapshots protect against

Snapshots are excellent for a specific and common set of problems: a volume failing, a bad deployment needing a quick rollback, a configuration change that broke something, a machine that needs cloning for testing.

They are fast to take and fast to restore, which makes them the right tool for routine operational recovery. Take them before risky changes as a matter of habit.

What snapshots do not protect against

Account compromise. An attacker with sufficient permissions deletes the snapshots along with the volumes. They are in the same account, protected by the same credentials.

Accidental deletion of the account or project. Everything inside goes together.

Regional failure, if the snapshots are stored in the same region.

Slow data corruption. If a bug has been quietly corrupting data for six weeks and your snapshot retention is thirty days, every snapshot you hold contains the corruption.

Ransomware, which increasingly targets backup and snapshot infrastructure deliberately and specifically.

Provider account issues. Suspension or a billing dispute makes everything inaccessible at once.

That last category is uncomfortable but real, and it is the reason a copy outside the provider has value out of proportion to how often it is used.

The rule worth keeping

The traditional formulation is three copies of the data, on two different media or platforms, with one off-site. A modern reading adds: one immutable, and one verified restore.

In cloud terms a reasonable interpretation is: the live data, snapshots in the same platform for fast operational recovery, and an independent backup somewhere with different credentials, ideally with object lock or equivalent immutability so it cannot be deleted even by someone holding valid credentials.

Immutability is the part that specifically defends against both ransomware and a malicious insider, and it is now widely available on object storage.

Retention that matches the failure modes

Retention is usually set to a single number, which does not match how failures actually present.

• Recent, frequent copies cover accidental deletion, which is noticed within hours. Hourly or daily for a week.
• Daily copies for a month cover mistakes noticed within a billing or reporting cycle.
• Weekly copies for a quarter cover slow corruption and problems discovered during an audit.
• Monthly copies for a year or more cover compliance and the occasional genuinely old restore.

The tapering matters because the failures you discover late are exactly the ones a short retention window cannot help with.

Test the restore, or you do not have a backup

This is the part that gets skipped, and it is the part that determines whether any of the above was worthwhile.

Backups fail silently in entirely mundane ways: the job stopped running months ago and nobody read the email, the database dump was taken without the right flags and is inconsistent, the encryption key is stored only on the machine being backed up, the backup captures the application but not the database, or the restore takes eleven hours and nobody knew.

The only way to find out is to restore. Once a quarter, restore into a throwaway environment and check that the data is actually usable, not merely that files appeared.

Measure how long it takes, because that number is your real recovery time objective regardless of what any document claims.

What people forget to back up

The database is remembered. These frequently are not:

• Uploaded files stored on the application server’s local disk.
• Configuration and secrets, without which the restored data cannot be used.
• TLS certificates and keys.
• Scheduled job definitions.
• Infrastructure definitions, if the environment is not defined in code.
• DNS records, which are often held at a registrar nobody has documented access to.

A restore that produces a working database and no way to run the application in front of it is a partial success at best. Write down what a complete recovery needs, and check the list against what you are actually storing.

Where you run this matters less than how, but if the provider is still open, the cloud account catalogue compares the options side by side.

For the vendor’s own reference on the services involved here, see the UpCloud documentation.

Reading about storage behaviour only goes so far; measuring it on a live server goes further. We stock UpCloud accounts in a single configuration, and the cloud account catalogue covers nine other providers.

Questions people ask