Small stacks, provided free disk space can hold the largest database dump and temporary archive.
Docker disaster recovery
How to Backup Docker Apps on a VPS
Build a usable backup routine for Docker volumes, databases and configuration, then test a real restore.
A snapshot is useful, but it is not a complete backup strategy. A VPS can be deleted, encrypted or misconfigured, and a backup stored on the same disk will disappear with it. The practical baseline is an off-server encrypted repository, a database-aware export, a copy of Docker configuration and a restore drill that proves the files are usable.
Containers are disposable; application data is not. Recreating an image does not recover a PostgreSQL database, uploaded files, secrets or the encryption key an application needs to read stored credentials. A useful backup leaves the VPS, has more than one restore point and has been restored somewhere other than the live server.
Snapshot and backup solve different problems
Provider snapshot
Fast whole-server rollback after a bad update. Usually tied to one provider account and one failure domain.
Application backup
Portable database dumps, volumes, configuration and keys stored outside the VPS and tested independently.
VPS requirements
Buy for the workload, not the install command
Database dumps, encrypted incremental backups and verification without starving the app.
Large databases, frequent retention points and a separate VPS for regular restore drills.
Use 3-2-1 as a design check
3copies of important data
2different storage types or systems
1copy away from the VPS provider
Before touching the server
- A second storage destination outside the VPS
- A list of Docker volumes and databases used by your apps
- A password manager entry for the backup repository password
- A temporary restore directory or spare VPS for testing
Back up the database, volumes and recovery context
01
Inventory the data
Record Compose files, .env files, Docker volumes, bind mounts, database names, upload directories and encryption keys. A backup without the key or Compose file may be impossible to restore.
docker volume ls
docker ps --format 'table {{.Names}}\t{{.Mounts}}'
find /opt -name compose.yml -o -name docker-compose.yml02
Export databases consistently
Use the database's own dump tool while the service is running, then back up the dump and application files. For PostgreSQL, pg_dump is usually safer than copying live data files byte-for-byte.
docker exec postgres pg_dump -U DB_USER DB_NAME > /backup/db-$(date +%F).sql03
Back up volumes to an encrypted remote repository
Restic encrypts the repository, but the password is not recoverable if you lose it. Store the repository password separately and use a retention policy that matches how far back you may need to recover.
restic -r s3:s3.amazonaws.com/BUCKET init
restic -r s3:s3.amazonaws.com/BUCKET backup /opt /backup
restic -r s3:s3.amazonaws.com/BUCKET forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune04
Schedule and observe the job
Run the backup from systemd timers or cron, capture exit codes and send an alert when the job fails. A green dashboard from last week is not proof that tonight's upload succeeded.
05
Perform a restore drill
On a temporary machine, restore one database and one application volume, start the Compose stack with a test hostname and verify logins, uploads, webhooks and scheduled jobs. Record the time and missing steps.
Common mistakes that cause real downtime
- Calling a provider snapshot a complete backup even though it shares the provider account and failure domain
- Copying live PostgreSQL files instead of making a database-consistent dump
- Backing up named volumes but forgetting Compose files, environment files and application keys
- Keeping the restic repository password only on the VPS being protected
- Watching successful backup logs for months without completing a restore test
A restore test is part of the backup
Restore to a temporary directory or spare VPS, import the database, recreate the containers and verify logins, uploads, scheduled jobs and webhooks. Until this works, you have backup files, not a recovery plan.
Before trusting the backup
The backup repository is on a different failure domain
A database dump can be opened or restored
The encryption password is stored separately from the VPS
A restore test has been completed and timed
Next step
Keep the deployment moving
Sources and further reading
- restic: create an encrypted repository
- n8n community: recovering a self-hosted instance
- n8n workflow: scheduled workflow and credential backup
- TechRadar: n8n hosting and backup guidance
Commands assume a fresh Ubuntu server. Replace domains, users, database names and provider-specific values before running them. VPS sizing is a practical starting point, not a guarantee: monitor the real workload and resize when CPU, memory, disk or network headroom becomes tight.