How to back up a VPS (and actually restore it)

The only backup that matters is the one you can restore. Hardware fails, updates go wrong, and a mistyped command can wipe a database — a good backup strategy turns any of those from a disaster into a minor inconvenience. Here's how to back up a VPS properly, in layers.

The three layers of backup

Think in layers, because each protects against different failures:

1. Whole-server snapshots — an image of the entire VPS at a point in time. Best for fast, complete recovery.
2. File-level backups — your app code, configs and user data, copied off-site.
3. Database dumps — a consistent export of your databases, since copying live database files can corrupt them.

Rely on more than one layer. Snapshots are great but you also want off-server copies you control.

Layer 1: Snapshots

A snapshot captures the full disk — OS, apps, data — so you can roll back the entire machine in minutes. Nxeon provides one-click snapshots and scheduled backups from the dashboard, stored independently of your VPS. Take a snapshot before any risky change (a major upgrade, a config overhaul) and you have an instant undo button.

Layer 2: File-level backups with restic

For versioned, encrypted, off-site file backups, restic is excellent. Install it:

sudo apt install restic -y

Initialize a repository (this can point at another server or object storage):

restic init --repo /mnt/backup/restic

Back up the important directories:

restic --repo /mnt/backup/restic backup /var/www /etc /home

restic deduplicates and encrypts, so repeated backups are fast and small. List snapshots and restore with:

restic --repo /mnt/backup/restic snapshots
restic --repo /mnt/backup/restic restore latest --target /tmp/restore

A simpler alternative for a straight mirror is rsync:

rsync -avz /var/www/ user@backup-host:/backups/www/

Layer 3: Database dumps

Never back up a running database by copying its files — you'll get a corrupt, inconsistent copy. Use the proper dump tool.

MySQL / MariaDB:

mysqldump --single-transaction -u root -p --all-databases > /backups/db-$(date +%F).sql

PostgreSQL:

pg_dumpall -U postgres > /backups/db-$(date +%F).sql

The dump is a plain SQL file you can restore cleanly onto any server.

Automate it with cron

Backups only work if they happen without you remembering. Schedule a nightly job:

sudo crontab -e

Add a line to dump the database and back up files at 2 AM:

0 2 * * * mysqldump --single-transaction -u root --all-databases > /backups/db-$(date +\%F).sql && restic --repo /mnt/backup/restic backup /var/www /backups

Keep copies off the server

A backup stored only on the same VPS disappears with the VPS. Push copies somewhere else — another server, object storage, or a home machine. The classic 3-2-1 rule: three copies, on two types of media, one off-site.

Prune old backups

Keep storage in check by retaining a sensible history:

restic --repo /mnt/backup/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

The step everyone skips: test the restore

An untested backup is a hope, not a plan. On a schedule, actually restore to a scratch location and confirm the data is intact — restore a database dump into a test database, or spin up a throwaway VPS and restore a snapshot to it. Nxeon makes this cheap: deploy a temporary VPS, restore, verify, and destroy it.

A sensible baseline

For most projects: nightly database dumps plus restic file backups off-site, scheduled snapshots from the Nxeon dashboard for whole-machine recovery, and a monthly restore test. That combination means whatever goes wrong, you're never more than a day from a known-good state — and you've proven you can get back there.