🐳 Docker From Scratch – Day 5: Docker Volumes & Persistent Storage Explained

🐳 Docker From Scratch – Day 5: Understanding Docker Volumes and Persistent Storage

In the previous article, we explored Docker Networking and learned how containers communicate with each other using Bridge Networks, Port Mapping, and Docker DNS. By now, you can build Docker Images, create containers, expose applications to users, and even connect multiple containers together. However, another important question arises when working with real-world applications. What happens to the data inside a container when that container is deleted? If you are running a MySQL database inside Docker and accidentally remove the container, will your database still exist? Understanding the answer to this question introduces one of the most important concepts in Docker—Persistent Storage using Docker Volumes.

Containers are designed to be lightweight, portable, and temporary. They can be created in seconds and removed just as quickly. This behavior is one of Docker's greatest strengths because it allows developers to deploy applications consistently across different environments. However, this temporary nature also introduces a challenge. Everything stored inside a container's writable layer disappears when the container is removed. For applications such as Nginx or Redis, recreating the container may not be a problem. But for applications like MySQL, PostgreSQL, MongoDB, or any software that stores user data, losing information every time a container is deleted would be unacceptable.

Imagine staying in a hotel during a vacation. While you are staying there, you keep your clothes, laptop, and personal belongings inside the hotel room. The room feels like your own space, but it actually belongs to the hotel. Once you check out, the room is cleaned, prepared for the next guest, and everything you left behind is removed. Docker containers behave in exactly the same way. They provide a temporary environment where your application can run, but anything stored inside the container disappears once the container is removed.

Let's understand this with a simple example. Suppose you start a MySQL container using Docker.

docker run -d \
--name mysql-db \
-e MYSQL_ROOT_PASSWORD=root123 \
mysql:8

After the container starts, you connect to MySQL and create a new database named company. Inside this database, you create multiple tables and insert important customer records. Everything works perfectly, and your application successfully retrieves the data from MySQL. At this stage, many beginners assume that the data has been permanently saved.

Now imagine that the container stops unexpectedly or you decide to remove it because you want to recreate it with a newer version of MySQL.

docker stop mysql-db

docker rm mysql-db

After creating another MySQL container, you connect to it expecting your database to be present. To your surprise, the database has completely disappeared. All the tables, records, and configurations are gone. This often shocks beginners because they assume Docker stores everything permanently by default. In reality, Docker containers are designed to be disposable. Removing the container also removes the writable layer that contained your data.

This behavior is not a limitation of Docker. It is actually a design decision. Docker encourages developers to separate applications from their data. Containers should be replaceable at any time without affecting important business information. To achieve this separation, Docker provides a feature called Volumes.

A Docker Volume is a special storage location managed by Docker that exists independently of containers. Unlike files stored inside a container, data stored inside a volume remains available even if the container is stopped, deleted, or recreated. The volume continues to exist until it is explicitly removed by the user.

Think of a Docker Volume as a bank locker. Imagine that you own valuable documents, jewelry, and important certificates. You would never leave them inside a hotel room because the room is temporary. Instead, you store them in a secure bank locker. Even if you change your house or move to another city, the contents of the locker remain safe. Docker Volumes serve exactly the same purpose. Containers may come and go, but the data stored inside the volume remains secure.

Container
      │
      ▼
 Docker Volume
      │
      ▼
Physical Storage

This separation between applications and data is one of the most important principles in containerized environments. Modern DevOps practices recommend treating containers as disposable resources while storing important data in dedicated storage systems such as Docker Volumes, cloud storage, or external databases.

Whenever a container writes data to a mounted volume, Docker redirects those write operations to the volume instead of storing them inside the container's writable layer. This means the application continues working normally, but the actual files are safely stored outside the container.

To understand this better, imagine writing a document on your laptop while automatically saving it to Google Drive. Even if your laptop crashes, the document remains safely stored in the cloud. Docker Volumes work similarly by storing application data outside the container's temporary filesystem.

Docker provides three different ways to persist data. The first and most commonly used method is Named Volumes, which are fully managed by Docker. The second method is Bind Mounts, where a directory from the host machine is directly mounted into the container. The third method is Anonymous Volumes, which Docker creates automatically without assigning a specific name. Understanding the differences between these storage mechanisms helps developers choose the right solution depending on the application's requirements.

Before learning each storage type individually, it is important to understand why volumes are considered a best practice in production environments. Imagine running an e-commerce website where thousands of customers place orders every day. If the database container crashes and all customer records disappear, the business could suffer significant financial losses. By storing database files inside Docker Volumes instead of inside the container, administrators can replace or upgrade containers without risking permanent data loss.

In the next section, we will explore the different types of Docker storage, understand when to use each one, and learn how to create, inspect, mount, and manage Docker Volumes using practical examples.