VPS Snapshot vs Backup: What
A VPS snapshot is a point-in-time image of a server's disk that usually lives in the same storage system as the server, while a backup is an independent copy kept on separate storage. Snapshots are built for fast rollback; backups are built for surviving the loss of the host, the account, or the provider.
On this page
The one-question test: same disk or different disk?
Forget the marketing labels for a second. Ask one question about any recovery point you own: if the server's storage disappeared right now, would this copy disappear with it?
If yes, you have a snapshot. If no, you have a backup. Restore speed, retention, granularity: all of it follows from that one answer.
Snapshots are block-level copies the hypervisor takes using copy-on-write. They're fast because nothing gets duplicated up front. Unchanged blocks stay shared until something writes to them. The trade-off is that the snapshot depends on the same physical layer as the running VM.
The plan behind Hosting Notes
Same 4 GB VPS and LiteSpeed stack we benchmark in these guides.
What a snapshot captures
A snapshot freezes the state of the virtual disk at a moment in time. On a KVM-based VPS that means the boot sector, the kernel, installed packages, config files, and application data, all as one image.
- Restore speed: usually minutes, often a single panel click.
- Granularity: whole-disk. Pulling back one accidentally deleted
wp-config.phpmeans mounting the image and digging. - Retention: short by design. Often a handful of restore points, sometimes hours or days.
- Best use: the safety net before a risky change. Kernel upgrade, PHP version bump, database migration, a plugin you don't trust.
One detail people miss: a snapshot of a running server is crash-consistent, not application-consistent. If MySQL was mid-write, the image reflects that. Quiesce the database first (flush and briefly stop writes) if you need the snapshot to restore cleanly.
What a backup has to do to count
A real backup satisfies four conditions. Skip any one of them and it turns into decoration:
- Lives elsewhere. Different disk, different machine, ideally a different provider or region.
- Keeps history. Multiple versions across days and weeks, so a corrupted file that synced everywhere last Tuesday is still recoverable.
- Restores at the right level. Single file, single database table, or full machine. You choose, not the tool.
- Has been tested. An untested backup is a hypothesis. Restore one into a scratch VM each quarter and confirm it boots and serves.
Snapshot vs backup, side by side
| Snapshot | Backup | |
|---|---|---|
| Storage location | Same platform as the VM | Separate disk, bucket, or region |
| Restore time | Minutes | Minutes to hours, depending on size |
| Granularity | Whole disk | File, table, or full image |
| Retention | Short, few restore points | Long, policy-driven |
| Survives host loss | Often no | Yes, by definition |
| Typical job | Undo a bad change | Recover from disaster or ransomware |
Where people get burned
- Treating snapshots as backups. The most common failure. The snapshot dies with the account, the billing dispute, or the storage array.
- Backing up to the same box. A
tararchive sitting in/rooton the server it protects is not a backup. - Never testing. Corrupted dumps and missing credentials surface only on the worst possible day.
- Ignoring the database. Copying files while MySQL runs gives you a torn dataset. Dump the schema properly.
Note
Automate the dump, not just the copy. A nightly cron job running mysqldump --single-transaction piped through gzip, then pushed to object storage with rclone, gives you versioned, off-machine recovery for very little effort, and it won't freeze the site while it runs.
A practical setup that costs little
Run both layers. Snapshot before every change window, because it's the fastest undo button you'll ever have. Then keep an independent backup on a schedule that matches how much data you can afford to lose.
When you're choosing where to run this, look for a provider that exposes both halves in the control panel rather than forcing you to bolt one on. Hostinger's VPS plans cover the snapshot side with in-panel image rollback on KVM infrastructure, and the entry tiers are cheap enough to run a second small box purely as a backup target. Pair that with off-site object storage and you've closed the gap that snapshots alone leave open.
The short version: snapshots protect you from yourself, backups protect you from everything else. You need both, and now you know which is which.
Frequently asked questions
Can I use a VPS snapshot as my only backup?
No. Snapshots typically live in the same storage system as the VPS, so losing the host, the account, or the provider takes the snapshot with it. Keep at least one independent copy on separate storage.
How long does restoring a snapshot take compared to a backup?
A snapshot rollback is usually a matter of minutes because blocks are shared copy-on-write and the platform swaps them back in place. Restoring a full backup means transferring data from external storage, which scales with the size of the image.
Are snapshots application-consistent?
Generally not. Most hypervisor snapshots are crash-consistent, capturing whatever was in flight. Quiesce the database — flush buffers and pause writes briefly — before taking a snapshot you intend to boot from.
How often should I back up a VPS?
Set the interval from your tolerance for lost data. If a day of orders or comments is unacceptable, back up more than once daily. Database dumps are cheap and incremental, so frequent runs cost little.
Does a snapshot replace version control or config management?
No. Snapshots are coarse rollback points, not a change history. Track configuration in Git or a tool like Ansible so you can rebuild a server deliberately rather than reverting an entire disk.
Ready to get started? Check out Hostinger's plans.