Backups are one of those things everyone knows they should do and not everyone actually does properly. Here's how I actually handle it across my infrastructure.
The rule I follow
3-2-1: three copies of data, on two different media types, with one offsite. In practice this means: the live data on the server, a backup on the NAS at home, and ideally a third copy somewhere else. Not every piece of data gets all three but anything important does.
What actually needs backing up
Not everything on a server needs to be backed up — you can always reinstall the OS and packages. What needs backing up is the stuff you can't easily recreate:
- Databases — PostgreSQL dumps, regularly
- Docker volumes — where persistent data lives
- Configuration files — nginx configs, .env files, Compose files
- SSL certificates — or just let Certbot reissue them
- Pterodactyl server data
PostgreSQL backups
pg_dump -U postgres dbname > backup-$(date +%Y%m%d).sql
Run this on a cron job, compress the output, ship it somewhere safe. Restoring from a dump is straightforward — the hardest part is having the dump in the first place.
The NAS as backup target
My UGreen NAS is the primary backup destination for server data. Rsync over SSH pushes backups from VPSes to the NAS on a schedule. Fast, reliable, and the data is physically in my house rather than only existing on a remote server.
Testing restores
A backup you've never tested restoring from is theoretical. Periodically actually restore something from backup — even just a database dump to a test environment — to verify that the backup is actually usable. Discovering your backups are corrupted at the moment you need them is a very bad time to find that out.