Back up your own data

Read that again if you are about to put something irreplaceable on a VPS. The rest of this page is what to do about it.

The rule

Your data needs to exist somewhere that is not this server, and you need to have restored from it at least once. A backup you have never tested is a hope.

A practical baseline is:

• the working copy on the VPS
• at least one backup on a different system
• at least one copy in a different physical location or provider

An attached directory or Docker volume on the same VPS is not an off-server backup. It disappears with the same disk.

Copy files off with rsync

From your own machine, pulling:

rsync -avz --delete root@203.0.113.10:/var/www/ ~/backups/web/

From the server, pushing to somewhere else:

rsync -avz /var/www/ backups@example.net:/srv/backups/web/

Dump a database first, always

Never copy a live database's data directory. Dump it.

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

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

Automate it

A daily cron entry is better than a perfect plan you never write:

sudo tee /etc/cron.daily/layerone-backup >/dev/null <<'EOF'
#!/bin/sh
set -eu
DEST=backups@example.net:/srv/backups/$(hostname -s)
STAMP=$(date -u +%Y%m%dT%H%M%SZ)
install -d -m 700 /var/backups/layerone
pg_dump -Fc mydb > "/var/backups/layerone/mydb-$STAMP.dump"
rsync -az /var/backups/layerone/ "$DEST/db/"
rsync -az --delete /var/www/ "$DEST/www/"
EOF
sudo chmod +x /etc/cron.daily/layerone-backup

Use an SSH key with no passphrase restricted to that command on the far side, not a password.

Set retention before the disk fills

Decide how many daily, weekly, and monthly copies you need, then enforce that policy at the backup destination. Do not keep only the newest copy: corruption, accidental deletion, and compromise may be copied successfully before you notice them.

Monitor both backup age and destination capacity. A scheduled command that has not produced a recent file is a failed backup even if cron itself ran.

Protect the backup

• Encrypt the connection in transit, such as SSH for rsync.
• Use encryption at rest at the destination, or encrypt the archive before it leaves the server.
• Give the backup credential write access only to that server's destination.
• Keep deletion credentials separate where possible, so a compromised VPS cannot erase every retained copy.
• Never put database passwords directly in a world-readable script.

Test a restore

On an isolated test system, restore the newest file and prove the application can read it. For a PostgreSQL custom-format dump:

createdb appdb_restore_test
pg_restore --clean --if-exists -d appdb_restore_test mydb-YYYYMMDDTHHMMSSZ.dump
psql appdb_restore_test -c 'select now();'
dropdb appdb_restore_test

Use a disposable database and the correct application checks for your workload. Record the restore steps and how long they take. Repeat the test after changing database versions, storage layout, encryption, or backup tooling.

Before anything destructive

Take a copy by hand before you reinstall, resize or destroy. Especially destroy: it is immediate and there is no undo.

Rebuilding instead of restoring

The best answer for a lot of servers is to not have state on them. If a server can be rebuilt from a script and a data dump, an outage is an inconvenience rather than a disaster. The Client API exists for exactly that: deploy, configure, restore, in one script.