I have a sad story today. I lost all my database changes I made since saturday.
We use mongodb (3.4.1) and in this particular case it was running inside its official docker container with mapped volume.
Container was created with docker-compose, docker-compose.yml looks like this:
version: "2"
services:
database:
image: mongo:3.4.1
restart: always
container_name: cvs-db
volumes:
- ~/data/db:/data/db
ports:
- "27017:27017"
~/data/db is just a regular folder created long time ago.
After I had restarted the container (with docker-compose up -d) the data returned to the state it was two days ago. Even deletions disappeared.
We cleaned up all collections yesterday and started to fill them up with real data and now it contains all the test data we removed recently.
So, my questions are: 1) how to protect mongodb data from such disasters? 2) can someone tell exact conditions which may lead to these results? 3) how do I restore the data?
EDIT: after some research I think it was the docker-compose fault. But the questions are still valid :)
Looking at your compose file, you're referencing the source dir as the relative ~/data/db. If you have more than one user account on the system that can access that compose file (i.e. root plus a named user account), then the "~/data/db" directory would be different depending on which user ran compose to start the container. Perhaps something like that happened in your environment.
You're better off using an absolute path to your host volume (i.e. /opt/data/db:/data/db) rather than something that can change based on the user or parent directory context to avoid the possibility of this type of problem.
Using a standard host directory as a data volume shouldn't lead to spontaneous rollback of data. If its not an issue with the directory context as mentioned above, then its possible there was some other factor involved like someone reverting a filesystem snapshot, restoring a backup or altering the DB directly.