VDS Backup Strategy: Are Snapshots Enough? The 3-2-1 Rule in Practice

"I take snapshots, so I have backups" is the most expensive misunderstanding when a server is lost. Snapshots are a powerful tool, but on their own they are not a backup. This article explains the difference, the 3-2-1 rule and how to set it up in practice on a Cloud VDS.

Snapshot versus backup

A snapshot is a frozen copy of the virtual disk at one moment, stored on the same storage. You take one with a click in the FiberVM panel and roll back in seconds. It is ideal before an OS upgrade, a major application release or a configuration change. It is not enough for:

• Location: a problem in the disk, storage or virtualisation layer affects the snapshot too.
• Consistency: a snapshot of a running database misses transactions still in memory; recovery may be needed after rollback.
• History: the number of snapshots is limited; it is the wrong tool for "one file as it was three weeks ago".
• Deletion: if the server is cancelled, the account is compromised or the VM is deleted by mistake, the snapshots go with it.

The 3-2-1 rule

Keep 3 copies of your data, on 2 different media, with 1 copy in another physical location. For a VDS that means:

Fiberserver's three locations give you the geographic separation: send the backups of your production server in Türkiye to a small VDS in France or Cyprus. The smallest plan with 1 core and 25 GB NVMe is enough as a backup target for most sites, and traffic is unlimited on every plan.

In practice: database dumps

Back up databases as dumps, not as files; it is the only consistent way. Nightly via cron:

mysqldump --single-transaction --quick --routines --all-databases | gzip > /var/backups/db/all-$(date +%F).sql.gz
find /var/backups/db -name "*.sql.gz" -mtime +7 -delete

Use pg_dumpall for PostgreSQL; with Docker the same commands run through docker compose exec db …. For WordPress sites include wp-content/uploads and wp-config.php as well.

In practice: encrypted, incremental, off-site backups with restic

restic is an open-source backup tool: it works incrementally (only changed blocks are sent), encrypts the backup and deduplicates repeated data. The target can be another VDS over SFTP or S3-compatible object storage.

apt install -y restic
export RESTIC_REPOSITORY=sftp:[email protected]:/srv/restic/web1
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /var/www /etc /var/backups/db --exclude /var/www/*/cache
restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 6 --prune

Put the commands in a script and schedule it with cron; inspect history with restic snapshots and rehearse a restore with restic restore latest --target /tmp/restore. Keep the password file somewhere else too: lose the password and you lose the backup.

How long to keep backups

• 14 daily copies: the "file deleted last week" scenario.
• 8 weekly copies: data corruption that is noticed late.
• 6 monthly copies: accounting and compliance needs.

Think about ransomware: an attacker who gets into the server may reach the backup target too. Give the SFTP user on the backup server write access to its own directory only, no delete rights (append-only), and block SSH logins to the backup VDS from the production server except for the key restic uses.

The restore test is the real backup

An untested backup is an assumption. Every three months: create a small temporary VDS in FiberVM, restore the latest restic snapshot into it, import the database dump, open the site through your hosts file and check it, then delete the temporary server. Write down how long it took; that recovery time is your real RTO.

Short checklist

1. FiberVM snapshot before every major change.
2. Nightly database dump and restic backup to another location.
3. 14 daily / 8 weekly / 6 monthly retention with automatic pruning.
4. Append-only user on the backup target, separate key.
5. Restore test every quarter, with the time recorded.
6. Email alert when a backup fails (route cron output with MAILTO).

If you want help setting this up, open a support ticket and we will plan a backup-target VDS in a second location with you.