As a beginner in using containers, I found myself facing a common challenge: not knowing how to define the volume location for my application data. Many of the templates I used would host the data within the container itself, which limited the benefits of using containers. To overcome this issue, I decided to revisit old containers and move the data out of the container to a backup folder on my host machine.

The first step was to create a backup folder on my host where I could move the data. I use Portainer, so my volume path would be: `/mnt/data`. Next, I logged interactively into the container using shell or bash, and validated the location of the data. In this case, I looked for a “data” folder or consulted the documentation to see where the data was stored. Once I found the folder, I copied the directory to the host machine outside the container.

To ensure that my data was properly backed up, I edited the docker-compose file and changed the configuration to define the new location of the volume where I wanted the data to reside. I started my container and observed the default directory structure. Then, I copied my backup data from the “backed up” directory (backup_dir) to the new location created by Docker. Finally, I restarted my container and verified that all my data was restored and working properly.

This experience taught me an important lesson about using containers effectively. By separating the application data from the container itself, I could ensure that my data was safely backed up and easily accessible. This approach also allowed me to upgrade my application without worrying about losing critical data.

In conclusion, moving your application data out of the container and into a backup folder on your host machine is an essential best practice for using containers effectively. By following this approach, you can ensure that your data is safely backed up and easily accessible, allowing you to focus on developing and deploying your applications without worrying about data loss or management.