Snapshots and server backups
If you run a VPS or cloud server, keeping copies of it is your job. Two tools help: snapshots, which capture the whole server at a moment in time, and backups, which copy your data somewhere else. This guide explains how they differ, why you need both, and how to make copies you can rely on when something goes wrong.
Snapshots and backups compared
A snapshot is a point-in-time image of a server's disk, taken by the hosting platform. Restoring it returns the whole server, including the operating system, settings, apps and data, to exactly how it was.
A backup is a copy of the data that matters, such as website files, databases and configuration, stored separately from the server. It can be restored to the same server or to a new one.
| Snapshot | Backup | |
|---|---|---|
| What it copies | The entire disk | The files and databases you choose |
| Where it is stored | With your hosting provider, usually alongside the server's account | Wherever you send it: another server, cloud storage or your computer |
| Restore | Whole server at once | A single file, a database or everything |
| Best for | Quick rollback before an upgrade or risky change | Recovering from data loss, hacks, account problems or mistakes found later |
Why snapshots are not enough
Snapshots are quick and convenient, but they depend on the same provider account as the server. If the account is compromised, closed or lost, or if the server is deleted along with its snapshots, they may be gone too. Restoring a snapshot also replaces everything, so you lose any changes made after it was taken, even if you only wanted one file back.
Keep regular off-server backups as well: copies stored outside your server and outside the provider account that holds it. Snapshots are a convenient extra layer, not a replacement.
Get consistent database copies
A database writes to its files constantly. A snapshot or file copy taken while it is busy can catch it half-way through a change, and the copy may not restore cleanly.
Export databases to a file first, then let the snapshot or backup include that export. For MySQL and MariaDB:
mysqldump --single-transaction --routines --triggers -u backupuser -p --all-databases > /var/backups/db/all-databases.sql
--single-transactiongives a consistent copy of InnoDB tables, the usual default, without locking the site.--routinesand--triggersinclude stored procedures and triggers, if your apps use them.-pasks for the password. For scheduled exports, store the credentials in a protected option file such as~/.my.cnfwith permissions600instead of typing them on the command line.
Other databases have their own tools, such as pg_dump for PostgreSQL. For the most consistent snapshot of a busy server, you can also stop the database service briefly while the snapshot is taken.
Back up off the server
- Decide what to include: website files, database exports, configuration (for example the
/etcfolder), and any app data stored elsewhere. - Choose a destination outside the server, such as cloud storage or another server.
- Use a backup tool that supports encryption and keeps several versions, such as
resticorborg, or copy files withrsync. - Run it automatically with a cron job, after the database export has finished, see Schedule tasks with cron jobs.
- Check the backup log regularly so you notice when a run fails.
Backups contain everything an attacker would want, including databases and configuration secrets. Encrypt them, and use credentials for the backup destination that cannot delete older copies from the server itself where your tool or storage allows it. That way a hacked server cannot erase its own backups.
Retention: how long to keep copies
Retention is how long you keep each copy. Problems are not always noticed straight away: a hack or a deleted page can go unseen for weeks. A common approach keeps several layers, for example:
- daily backups for the last week or two
- weekly backups for the last month or two
- monthly backups for several months
Delete old snapshots you no longer need too. They can use storage and may make it harder to find the right one.
Test your restores
A backup you have never restored is untested. Every few months:
- Create a new, temporary server, or restore to a separate test location.
- Restore the files and import the database export.
- Check that the site or app works, then delete the test server.
Note how long the restore took and anything you had to look up, and write it down. Those notes will save time when a real restore is needed.
Take a snapshot before every major change, such as an operating system upgrade or a control panel installation, so you can roll back in minutes if it goes wrong.
DomainPilot VPS and cloud servers include snapshots. VPS is self-managed, so off-server backups of your data are your responsibility. Set them up alongside your snapshots.