Two tools that do not make the same promise
A snapshot freezes the state of a disk at a given moment so you can return to it quickly. A backup copies the data elsewhere, with a history, so you can rebuild after a loss. Hosting panels often use the two words as synonyms, and that is where the misunderstanding starts: the snapshot button feels safe, yet it only answers part of the possible disasters.
For an agency hosting client sites on VPS, the nuance has a direct cost. The day a machine disappears, the client does not ask whether a snapshot existed: they ask when the site will be back and with which data. This article offers a simple criterion to choose, VPS by VPS, between rollback and rebuild, then a way to write it into the contract.
What a snapshot does very well
- Rollback in minutes — before a version upgrade, a configuration change or a migration, returning to the previous state is fast.
- A dated reference point — you know exactly which moment you return to, which simplifies diagnosis after an incident.
- No rebuild to carry out — the machine restarts as it was, system settings included.
- An accessible action — one click or one command in the panel, with no tool to install and no repository to configure.
- Suited to trials — test an update on a client site while keeping an emergency exit.
- Useful before a human intervention — an administration mistake can be undone without a long restore.
The objection: "I already have snapshots"
A snapshot most often lives with the same provider, on the same storage and under the same account as the machine. It therefore shares its failures. If the VM is deleted, by mistake or after an unpaid invoice, the attached snapshots may disappear with it, depending on the provider. If the hosting account is compromised, whoever gets in can delete the machine and its snapshots in one go. If the underlying storage has an incident, the copy and the original fall together.
Two more limits apply. A snapshot is consistent at disk level, not at application level: a database in the middle of a write may appear in an unfinished state. And a snapshot is never proof of restoration: until you have read it back, it is a hypothesis.
An honest counter-objection: none of this makes the snapshot useless. It remains the fastest tool for going back before a risky operation. You should not throw it away; you should stop asking it to do what it cannot do.
Snapshot and off-machine backup, criterion by criterion
Scroll the table
| Criterion | Snapshot | Off-machine backup |
|---|---|---|
| Location | Most often with the same provider, on the same storage | Outside the VM's provider, on separate storage |
| Survives deletion of the VM | Varies: depending on the plan, it may disappear with the machine | Yes, the copy exists independently of the machine |
| Survives compromise of the hosting account | No, same credentials as the VM | Yes, if repository access is separate from the hosting account |
| Application consistency | Disk consistency only | Possible with an application export made before the copy |
| Retention | Short, often a few recent points | Long, with a history and a retention you choose |
| Rollback speed | Very fast | Slower: the data has to be copied back |
| Encryption before transfer | Rarely under your control | Possible, with a key you keep |
| Proof of restoration | None until tested | None until tested, hence the scheduled test |
Application consistency: the database trap
Copying a disk while a database is writing is like photographing a page mid-turn. The file system is healthy, but the database may hold a half-written transaction, and it will sometimes recover after a repair phase and sometimes not. The remedy is to produce a consistent export of the database before the snapshot or before the copy, then include it in what gets backed up.
For PostgreSQL, the documented command is pg_dump, which produces a consistent export even while the database serves queries. For MySQL and MariaDB with InnoDB tables, mysqldump --single-transaction reads a consistent state without blocking writes. In both cases the export file joins the backup, and it is the file you restore first. This applies as much to a snapshot as to a file copy: the disk alone guarantees nothing about the logical state of the database.
Four disasters, four protections
Scroll the table
| Disaster | What protects you | Why |
|---|---|---|
| An update breaks the system | A snapshot taken just before | Fast rollback to a known state |
| A file or table deleted by mistake, discovered several days later | A backup with history | The recent snapshot already contains the error: you need an older point |
| VM deleted or hosting account compromised | A backup outside the provider | The copy depends on neither the machine nor the account |
| Silent corruption discovered late | A backup with long retention | You must go back to before the data started to degrade |
The decision rule in one sentence
Snapshot: a short rollback before a risky operation. Backup: the ability to rebuild after losing the machine or the account.
If the question is "can I undo what I am about to do within the hour", the snapshot answers. If the question is "what is left if this machine or this account no longer exists tomorrow", only the off-machine backup answers. A serious client VPS therefore has both, with roles that do not overlap.
The two are not in competition. The snapshot is taken before the intervention and deleted once the result is validated, while the backup runs on a fixed schedule that nobody has to trigger by hand. Mixing up these rhythms causes most of the bad surprises: a snapshot forgotten for weeks takes up space and protects very little, while a backup triggered only before major work leaves gaps in the history.
Apply the rule to each client VPS
Inventory the VPS and what they carry
For each machine, note the sites, databases, uploaded files and how critical they are for the client.
Set the acceptable data loss
Ask how many hours of data the client can lose. This value is the RPO: it dictates the backup frequency.
Set the acceptable recovery time
Ask how long the site can stay offline. This value is the RTO: it dictates the rebuild method.
Put the backup outside the VM's provider
Use separate storage, with credentials distinct from the hosting account, and encrypt before sending with a key you keep.
Add the database export before each copy
Run
pg_dumpormysqldump --single-transactiondepending on the engine, and include the resulting file in the backed-up set.Keep the snapshot for risky operations
Take a snapshot before each version upgrade or major change, then delete it once the result is validated.
Test the restore: without a test, a hypothesis
A backup that has never been restored in a test is only a hypothesis. The difference between snapshot and backup also lies in proof: only a timed restore exercise tells you whether the site restarts and how long it takes.
Our guide on the restore-test procedure for an agency details the quarterly exercise on a disposable VPS, the measurement of the observed RTO and RPO, and the log to hand to the client. We do not repeat it here. Keep the principle: schedule the test, date it, and fix what it reveals, whether missing access, absent secrets or a different software version.
For implementing a tool, the guide on the 3-2-1 strategy with Restic and S3 summarises in one paragraph what a provider snapshot does not guarantee, then shows an off-provider backup in practice. This article deliberately stays conceptual: it is for deciding, not installing.
Write the rule into the contract
An agency contract benefits from stating what is protected, by which mechanism and with which objective, rather than promising "backups". Three elements are enough: the RPO, meaning the maximum data loss accepted; the RTO, meaning the target time to restore service; and the mechanism that holds both values.
Fictional example, to adapt and not to copy as is: "Site data is copied every night to storage located outside the machine's host, with several months of retention. The provider commits to an RPO of 24 hours and an RTO of 8 hours after the decision to restore. A snapshot is taken before each major update and deleted after validation. A test restore is carried out every quarter and its log is given to the client."
These figures are invented for illustration. Yours must come from your own restore measurements, not from an intention.
Before the risky operation: snapshot and verified backup
Before a version upgrade, take the snapshot, but also check that the latest off-machine backup is recent and readable. The snapshot helps if the operation fails quickly. The backup helps if the problem shows up three days later, when the snapshot has already been deleted.
A policy per client, and what ServOrbit puts within reach
An agency can keep its backup policy in a simple table: one line per client, with the RPO, the RTO, the mechanism and the date of the last test.
On the web hosting side, backups are weekly on entry-level plans, daily on the Pro plan and on all reseller plans, with a premium daily backup available as an option. For a VPS, the existence and terms of snapshots depend on your provider's plan: check the panel documentation before writing them into a contract, and never count them as your only copy.
