What actually needs backing up
Three things: your data (databases, uploaded files), your configuration (nginx/systemd/env files), and the knowledge of how to rebuild the rest. Do not image the whole disk out of fear — OS and packages are reproducible; your database is not.
A setup that works
Databases: a nightly dump (pg_dump --format=custom for Postgres, mysqldump for MySQL) via cron or systemd timer, compressed, with 7 daily + 4 weekly retention.
Files and config: an incremental tool like restic or borg to an offsite target (object storage such as S3/R2/B2). Offsite is non-negotiable — a backup on the same VPS dies with the VPS.
Provider snapshots are a good extra layer for fast whole-machine recovery, but they are not a substitute: they live in the same account and region as the machine they protect.
The restore test is the backup
An untested backup is a hope, not a backup. Monthly: restore the latest dump into a scratch database, count a few tables, open the app against it. Write the restore commands down where the panicking future you will find them.
Where SimDeploy fits
For projects deployed on SimDeploy, the artifact-based model changes the equation: your source of truth is your repository, every deploy is a rebuildable artifact, and there is no server state to lose. The backup discipline above remains essential for the databases and machines you run elsewhere.
FAQ
How often should a VPS be backed up?
Databases: at least daily, more often if the data changes fast. Files/config: daily incrementals are cheap with restic/borg. Snapshots: weekly plus before risky changes.