A Practical Backup and Snapshot Strategy for Your VPS

Replication is not a backup

On VeloxMedia, every disk is replicated across nodes, so a failed drive or host does not lose data. But replication copies every change instantly, including mistakes. If you run DROP TABLE or a script deletes a directory, the replicas faithfully do the same. Backups give you points in time to go back to.

The three layers

1. Snapshots for instant rollback before risky changes.
2. Scheduled backups of the whole server, kept off the host, for recovery from bad days.
3. Application-level copies (database dumps, file sync) stored with a different provider or location, for the worst days.

Layer 1: snapshots before changes

Take a snapshot from the control panel before OS upgrades, major application releases, schema migrations or anything you are not sure about. They take seconds and restoring rolls the whole server back. Treat them as short-term: delete them once the change has proven itself, because they are not a substitute for scheduled backups.

Layer 2: scheduled server backups

Enable scheduled backups in the control panel so full-server copies are kept off-host automatically. Restoring rebuilds the server from a chosen point, which is the fastest way back from a compromised or badly broken system.

Layer 3: database dumps and off-site copies

Whole-server backups of a running database can capture files mid-write. A logical dump is consistent and portable:

# PostgreSQL
sudo -u postgres pg_dump -Fc mydb > /var/backups/mydb-$(date +%F).dump

# MySQL / MariaDB
sudo mariadb-dump --single-transaction --routines --triggers mydb | gzip > /var/backups/mydb-$(date +%F).sql.gz

Then send dumps and important files to storage outside your hosting account, so a lost password or a compromised account does not take the backups too. restic encrypts, deduplicates and works with S3-compatible storage, SFTP and many other targets:

sudo apt install -y restic
export RESTIC_REPOSITORY=s3:https://s3.example.com/my-bucket/web1
export RESTIC_PASSWORD_FILE=/root/.restic-pass
export AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=...
restic init
restic backup /var/backups /var/www /etc
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Put the dump and restic commands in a script and run it nightly from cron or a systemd timer. Store the restic password somewhere other than the server; without it the backups cannot be decrypted.

Retention that makes sense

A simple schedule that suits most sites: daily backups kept for a week, weekly for a month, monthly for six months. Ransomware and silent corruption are often noticed late, so older copies matter more than people expect.

Test restores

A backup you have not restored is an assumption. Once a quarter:

1. Deploy a temporary Micro or Small server.
2. Restore the latest dump and files onto it.
3. Check the application starts and recent data is present.
4. Note how long it took, then delete the server.

The time it takes is your real recovery time, and it is far better to learn it on a quiet afternoon.

Checklist

• Snapshot before every risky change
• Scheduled off-host server backups enabled
• Nightly database dumps
• Encrypted off-site copies with sensible retention
• Backup password stored away from the server
• Quarterly restore test on a scratch server