I need to run a database for a server and am deciding whether to deploy it with Docker Compose or install it directly on the host. I'm concerned about data safety after power outages because we've previously seen corruption in MongoDB and MariaDB/MySQL. The database would use local persistent storage. How well do databases such as PostgreSQL handle abrupt shutdowns in containers, and what configuration or backup practices should I use?
4 Answers
We’ve run MongoDB containers at work and MariaDB and InfluxDB containers in a home lab without significant problems. The key is using persistent storage, avoiding accidental volume deletion, monitoring disk capacity, and maintaining tested backups. A volume protects data across container recreation, but it is not a backup.
Docker itself usually isn’t the main risk. Put the database data on a persistent volume, and the files will survive container restarts just as they would with a normal host installation. A container crash is generally handled like any other database process crash. Make sure the database’s durability settings, such as fsync or WAL, remain enabled, and give it enough time to shut down cleanly in Compose.
For local storage, Docker Compose is a reasonable choice. Set an appropriate stop grace period so the database has time to flush and shut down, keep durability features enabled, and store backups somewhere separate from the host. That way a damaged disk, host failure, or unrecoverable database issue does not take out both the live data and its backup.
PostgreSQL is commonly run in Docker with a local volume and should recover well from unexpected shutdowns when fsync is enabled. Still, a UPS is more useful than choosing between a container and a host install when the underlying problem is sudden power loss. The storage device and host remain the important failure points.
In our case, disk space has caused more incidents than Docker or the database runtime. Monitoring free space and setting alerts is definitely worthwhile.