VPS Backup Strategy: The 3-2-1 Rule, Snapshots vs Backups, and Testing Restores

Most people discover their backup strategy on the worst day: after a failed update, a hacked plugin, a deleted database or a disk failure. A good strategy is not complicated, but it has to answer three questions in advance: what you back up, where the copies live, and how fast you can restore. This guide gives you a practical setup for a VPS.

The 3-2-1 rule, adapted for a VPS

• 3 copies of your data: the live server plus two backups.

• 2 different storage types: for example, the provider's backup system and separate object storage.

• 1 copy off-site: outside the server and ideally outside the provider account, so a compromised account or a deleted server does not take every copy with it.

Snapshots vs backups: not the same thing

• Snapshot: a point-in-time image of the whole disk. Fast to create and restore, ideal before risky changes such as OS upgrades. Usually stored on the same infrastructure, so it is not a full disaster-recovery plan on its own.

• Backup: a copy of files and databases stored separately, kept for a period of time, and restorable even if the server is gone.

Use snapshots for quick rollbacks and backups for real recovery.

What to back up

• Databases, using proper dump tools, not by copying live database files.

• Application files and uploads, such as /var/www.

• Configuration: web server configs, environment files, cron jobs, SSL setup and Docker compose files.

• Secrets kept in a password manager, so you can rebuild access after a restore.

A simple automated setup

# database dump (MySQL/MariaDB)
mysqldump --single-transaction --all-databases | gzip > /backup/db-$(date +%F).sql.gz

# PostgreSQL
pg_dumpall | gzip > /backup/pg-$(date +%F).sql.gz

# encrypted, deduplicated off-site copy (restic)
restic -r s3:https://your-storage/bucket backup /var/www /backup
restic -r s3:https://your-storage/bucket forget --keep-daily 7 --keep-weekly 4 --prune

Run the dumps from cron before the off-site job, keep encryption keys outside the server, and alert yourself if a job fails.

Retention: how long to keep copies

A common starting point is 7 daily, 4 weekly and a few monthly copies. Longer retention protects you from problems you discover late, such as a silent infection or data deleted weeks ago.

Test restores, or you do not have backups

1. Once a month, restore a backup to a fresh server or a staging environment.

2. Check that the site loads, logins work and the database is complete.

3. Time the process. That time is your real recovery time.

4. Write the steps down so anyone on the team can repeat them.

Common mistakes

• Keeping the only backup on the same server.

• Backing up files but not the database, or the other way round.

• Never testing a restore.

• No alert when a backup job silently stops.

Backups included at IM HOST

Every Cloud VPS includes a free automatic backup every 72 hours for the whole subscription, with no downtime while it runs, and our support team can restore it on request. On a Linux VPS, daily backups are available as an add-on, and our WordPress Hosting and Shared Hosting plans include free daily backups for the whole subscription. Combine the provider backup with your own off-site copy and you have a complete 3-2-1 setup.