Both snapshots and backups let you go back to an earlier state, which is why they get treated as the same thing. They protect against different failures, and the gap between them is where data actually gets lost.
What a snapshot is good at
A snapshot captures a server or volume at a point in time, usually stored on the same infrastructure. Creating one takes seconds and restoring is quick, which makes it excellent for planned, reversible risk.
Before a major upgrade, before editing a configuration you do not fully understand, before a deployment you are unsure about — take a snapshot, do the risky thing, and roll back in minutes if it goes wrong. Used this way, snapshots remove most of the fear from routine maintenance.
Where a snapshot will not save you
The weakness is that a snapshot usually lives in the same account, on the same platform, as the thing it protects.
If your account is compromised, an attacker with sufficient access can delete the snapshots along with the server. If you delete the wrong resource, the snapshots attached to it may go with it. And a snapshot taken while a database was mid-write is a crash-consistent image, not a clean one — it will usually recover, but usually is not a word you want in a recovery plan.
There is also a quieter failure: snapshots are point-in-time and typically retained briefly. Data corrupted three weeks ago and noticed today is beyond their reach.
What a backup adds
A backup is a copy of data stored independently of the production environment, with retention long enough to cover problems you discover late. The independence is the entire point.
For databases, this means a proper dump or a replication-based backup taken through the database's own tooling, which produces a consistent copy rather than a frozen image of files mid-write.
A strategy that survives contact with reality
The old 3-2-1 guideline still holds up: three copies of the data, on two different kinds of storage, with one of them somewhere else entirely. Translated to a cloud server, that is roughly: the live data, automated snapshots for fast rollback, and backups written to storage in a different account or provider.
Two additions matter more than the numbers. Retention should be long enough to catch slow problems — a corrupted table or a bad migration is often noticed weeks later, so keep some weekly and monthly copies rather than only the last seven days. And backups must be stored where the production server cannot delete them, using write-only credentials or a separate account, so that compromising the server does not compromise the recovery.
The step almost everyone skips
An untested backup is not a backup, it is an assumption. The only way to know is to restore one into a temporary server and check that the application actually starts and the data is complete.
Do this once when you set it up, and once every few months afterwards. It routinely uncovers the same small things — a missing database user, an uploads directory nobody included, a configuration file that lived outside the backup path — and it is far better to find them on a Tuesday afternoon than during an outage.
Write down how long a restore takes. That number, not the backup schedule, is what determines how long you are down.