When I installed Devilbox a few years ago, I doubled-checked that HOST_PATH_MYSQL_DATADIR is set correctly and that the databases are in the data directory. Peace of mind.
Last week, as I was struggling against Covid, when I started the Devilbox my app couldn’t connect to the DB ; I noticed that for some reason Devilbox recreated the container for MySQL. No problem I thought, my databases are still there and this is a backed up folder. But wait! these files are old?!? more that two years!
Then I checked the current docker-compose.yml and I was horrified to see that:
Where did you find that putting valuable data in a docker volume is a best practice? it really doesn’t sound good to me. If the volume becomes dangling (which it will be now that “docker-composer down” removes the containers), a simple “prune” would erase the data without warning.
The upgrade instructions were to import at upgrade time, so it wouldn’t gave give me a recent backup of the data in the docker volume.
So what I should have done is to add another backup mechanism (in add to the ones I already have) to find out which of the many docker volumes has valuable data, find out which containers are connected to these volumes, spin up these containers, one at a time, trigger a live backup to a set of flat files for each of them and spin down the container… sound awfully complicated and error-prone.
Docker volumes are transient by nature. If the “stack” is down (like in “docker-compose down”), the volumes, including named volumes, become orphans and will be potentially cleaned up (those volumes can pile up fast on a dev machine).
That’s why one should never put valuable data in docker volumes, unless one have set up a special mechanism to keep the volumes locked.
For those interested, I used the override mechanism like this:
I would disagree here. It depends on the data. Files and configuration should be mounted, anything else like DB data or similar should be a named volume. Afaik this also has performance benefits.
Additionally I would recommend docker-compose stop instead of docker-compose down. Nonetheless, docker-compose down does not delete volumes by default, you need to explicitly add the -v switch to delete the volumes:
For future prune operations, I would recommend to exclude volumes you want to keep. See example below:
docker volume prune --filter label!=keep
Another crucial thing to consider is to make regular backups for any kind of data which is important to you. Devilbox has documentation for how to do it with its stateful stuff. See here for example:
