Back up and restore

A backup job is only a promise. A restore test is evidence.

Decide what must survive

Back up application data, required configuration, and recovery instructions without blindly copying live secrets. For a typical VPS that means the database, uploaded files, and the handful of config files you wrote by hand — not a raw copy of the whole disk:

sudo -u postgres pg_dump blog > /backup/blog-2026-08-03.sql
tar czf /backup/blog-files-2026-08-03.tar.gz \
  /srv/blog/uploads /etc/blog /etc/nginx/sites-available

Keep copies out of reach

Keep copies separate from the server and protect deletion. A backup stored under the production root credential can be deleted during the same compromise. Independent access and version retention improve survival, but require a separate recovery procedure.

Ship the archives somewhere the server can write but not delete: object storage with versioning enabled, or a backup host that pulls from the server instead of receiving pushes.

Restore is the real test

Restore into a clean environment, verify integrity, and record recovery time and missing steps:

sudo -u postgres createdb blog_restore
sudo -u postgres psql blog_restore < blog-2026-08-03.sql
sudo -u postgres psql blog_restore -c "select count(*) from posts;"
#  count
# -------
#   1773

Verify application meaning after restoration, not only file presence. Row counts, checksums, a login, and one representative read provide stronger evidence that the recovered system is usable.

The classic failure looks like this: nightly dumps ran for a year, but the database password changed in March, and every archive since then contains an error message instead of data. Nobody noticed because nobody restored. You catch this by alerting on archive size drops and by rehearsing the restore on a schedule.

Restore application data and required configuration onto a clean host and record checksums, missing steps, and recovery time. Delete or corrupt one source file, then prove an older protected version restores correctly.