Who This Is For
Intermediate.
Think of it like photocopying the actual documents before shredding the originals, not just the empty folder they were sitting in. Copy the wrong thing and the backup is worthless the day you need it.
What You'll Build
A scheduled encrypted backup of at least one Docker application, with a documented restore test.
Prerequisites
- Docker host with at least one stack to back up
- A backup destination, USB disk, NAS share, SFTP, or object storage
Compose Files Are Not Backups
A compose.yaml recreates the service definition, it says nothing about the data inside volumes and bind mounts, which is what actually needs backing up.
Initialize a Repository
$export RESTIC_PASSWORD=your-strong-password
$restic init
Back Up a Stack
Exclude Disposable Files
Handle Database Consistency
Briefly stop the service, or use the application's own export/dump tool, so you're not backing up a database mid-write.
$restic backup ./data
$docker compose start
Schedule It
A systemd timer or cron job running the backup command daily is enough to start.
Retention and Pruning
Restore Test
Security & Backup Notes
- Losing the repository password means losing the backup entirely, store it somewhere durable and separate from the server itself
Troubleshooting
- Repository password loss, unrecoverable by design; this is why the password needs a separate, durable backup of its own
- Incorrect include/exclude patterns, always run a restore test after changing exclude rules to confirm nothing critical was skipped
- Backup captures a database mid-write, stop the service or use a proper dump tool first
- Repository fills up, run
forget+pruneon a schedule, not just backup - Prune takes longer than expected, normal on large repositories; run it during low-usage hours
Lab Finish Line
Scheduled encrypted backup of at least one Docker application and a documented restore test.