My bargain-basement cloud service provider, CloudAtCost recently lost one of my servers and all the data on it. This loss was exasperated by the fact that I didn’t backup my MongoDB data somewhere else. Now I’m working out the exact process after the fact so that I don’t suffer this loss again (it’s happened twice now with CloudAtCost, but hey, the price is right).
The following is a brute-force backup and recovering process. I suspect this approach has its weaknesses in that it may depend upon version-consistency between the MongoDB containers. This is not ideal for someone like myself who always installs the latest version when creating new containers. I aim to develop a more flexible process soon.
I have a server running Ubuntu 16.04, which, in turn is serving up a Dockerized Express application (Nginx, MongoDB, and the app itself). The MongoDB data is backed up in a data-only container. To complicate matters, the application allows file uploads, which are being stored on the file system in the project’s root.
I need to dump the data from the data-only container, bundle the uploaded files, and restore it all on another server. Here’s how I did it…
docker-compose to manage my containers. To obtain the name of the MongoDB data-only container, I simply run
docker ps -a. Assuming the name of the container is
This will put a file called
backup.tar in the app’s root directory. It may belong to the
root user. If so, run
sudo chown user:user backup.tar.
The app allows file uploads, so the database is pointing to a bunch of files stored on the file system. My files are contained in a directory called
Now I have two archived files:
Here I use
In the previous command, for simplicity, I transferred the files into the user’s home folder. These will need to be moved into the root of the project folder on the new server. Once there, assuming the same app has been setup and deployed, I first unpack the uploaded files:
Then I restore the data to the data container:
The project containers don’t need to be running when you restore the data in the previous step. If they are running, however, once the data is restored, remove the running containers and start again with
I’m sure there is a reasonable explanation as to why removing the containers is necessary, but I don’t know what it is yet. In any case, removing the containers isn’t harmful because all the data is on the data-only container anyway.
As per the introduction, this process probably depends on version consistency between MongoDB containers.