Most VPS providers offer a snapshot feature — a point-in-time image of your entire server. Snapshots are fast and convenient but have important limitations you should understand before relying on them as your only backup method.
What a Snapshot Actually Captures
A full image of your VPS's disk at a specific moment — operating system, installed software, configuration, and data, all together.
Snapshots vs Application-Level Backups
| Factor | Provider Snapshot | Application-Level Backup (mysqldump, rsync) |
|---|---|---|
| Speed to create | Fast, often a single click | Depends on data size, but can be selective |
| Restore speed | Fast, restores entire server | Requires manual restore steps |
| Location | Typically same provider/infrastructure | Can be genuinely off-site |
| Granularity | All-or-nothing (whole server) | Can restore just a database or specific files |
| Database consistency | Depends on provider's snapshot technology | Can be taken with proper database-aware locking |
When Snapshots Are the Right Tool
- Before a risky change (major update, configuration change) — a quick rollback point
- Full server migration or cloning
- Fast recovery when downtime cost outweighs data granularity needs
When Snapshots Alone Aren't Enough
- They typically don't satisfy the "off-site" requirement of the 3-2-1 rule, since they usually live on the same provider's infrastructure
- Database consistency isn't always guaranteed unless the snapshot mechanism is database-aware
- You can't easily restore just one file or table without restoring the entire server
Taking a Manual Snapshot Before a Risky Change
Standard practice before:
- Major OS/kernel upgrades
- Significant configuration changes (firewall, SSH hardening)
- Application deployments with database migrations
The exact process varies by provider — typically found in your control panel under the VPS management section.
Scheduling Automatic Snapshots
Many providers support scheduled automatic snapshots (daily/weekly) as an add-on — check your provider's control panel for this option, and confirm the retention policy (how many snapshots are kept before older ones are automatically deleted).
Ensuring Database Consistency in Snapshots
If your snapshot mechanism isn't database-aware, briefly stopping database writes (or using a database-level backup alongside the snapshot) avoids capturing the database mid-write in an inconsistent state:
sudo systemctl stop mysql
# trigger snapshot here
sudo systemctl start mysqlThis causes brief downtime — weigh this against your specific consistency requirements.
Restoring from a Snapshot
Typically done through your provider's control panel — select the snapshot and choose to restore or create a new VPS from it. Confirm whether restoring in-place overwrites the current server or creates a new one, since this differs by provider.
Recommended Combined Strategy
- Use snapshots for fast rollback before risky changes
- Use application-level backups (database dumps, file sync) for granular, genuinely off-site protection — see How to Set Up Automated VPS Backups
- Together, these satisfy both convenience (snapshots) and the 3-2-1 rule's off-site requirement (application-level backups)
Common Errors
Snapshot restore takes longer than expected — large disk sizes take proportionally longer; factor this into your RTO planning (see How to Create a Disaster Recovery Plan for Your VPS).
Related Articles
- Backup Strategy 101: The 3-2-1 Rule Explained
- How to Set Up Automated VPS Backups (rsync, cron & Off-Site Storage)
- How to Create a Disaster Recovery Plan for Your VPS
