Docker · Containers in practice
How do you back up data stored in Docker volumes?
Short answer
Back up with a consistent database dump or a volume snapshot, store copies off the host, and test restores regularly. A volume copy alone is not a reliable backup.
A file-level copy of a live database volume can be inconsistent because writes continue during the copy. Prefer a database-native dump or a storage snapshot that is crash-consistent, then verify the restore path.
docker run --rm -v pgdata:/data:ro -v "$(pwd)":/backup alpine \
tar czf /backup/pgdata-$(date +%Y%m%d).tgz -C /data .
docker run --rm -v pgdata:/data -v "$(pwd)":/backup alpine \
sh -c "rm -rf /data/* && tar xzf /backup/pgdata-20261028.tgz -C /data"What a backup plan needs
- A defined RPO and RTO so the backup frequency matches the business need
- A consistent method: database dump, filesystem snapshot or both
- Copies on different storage and, ideally, in a different region
- Encryption at rest and access control for backup data
- Scheduled restore tests, not just scheduled backups
- Retention that covers the recovery window and compliance requirements
Snapshots are fast but may depend on the storage system and can be inconsistent for an application. Dumps are portable but slower and need enough disk space. Many teams use both: frequent snapshots for fast recovery and periodic dumps for portability.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Why can copying a live database volume be unsafe?
- 2How do you define RPO and RTO for a service?
- 3Where should backups be stored?
- 4How often should you test a restore?
Say it in the interview
I back up with a consistent method such as a database dump or a storage snapshot, store copies off the host and preferably offsite, and test restores on a schedule. The plan starts from the RPO and RTO, because that determines frequency and tooling. A tar of a live volume is convenient but can be inconsistent, so I do not rely on it for a database.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Docker mock interview and get scored feedback on depth, clarity and confidence.