πΎ Docker Volumes & Data Persistence
A complete, hands-on guide to keeping your data safe even when containers are deleted β with 5 real-world labs you can copy-paste and run right now!
π Table of Contents
- The Problem β Why Data Gets Lost
- Easy Analogy β Hotel Room & Locker
- 3 Types of Docker Storage
- π§ͺ Lab 1 β Prove Data Loss Without Volumes
- π§ͺ Lab 2 β Named Volumes (MySQL Persistence)
- π§ͺ Lab 3 β Bind Mounts (Live Code Reload)
- π§ͺ Lab 4 β tmpfs Mount (RAM Storage)
- π§ͺ Lab 5 β Docker Compose with Volumes
- Essential Volume Commands
- Comparison Table
- π Cheat Sheet
- Summary & What's Next
1π± The Problem β Why Container Data Gets Lost
Before we dive into volumes, let's understand why this problem exists. Docker containers are designed to be ephemeral β meaning they are temporary by nature. This is a feature, not a bug! But it creates a serious challenge when you need to store data.
β οΈ Critical Rule to Remember
Every time you delete a Docker container,ALL data stored inside is permanently deleted. This includes databases, uploaded files, logs, and configuration changes.
π΄ Real-World Problems This Causes
- Database Data Lost: You run MySQL in a container, insert 10,000 records, delete the container β all records gone forever!
- Uploaded Files Lost: Users upload profile pictures to your app container β you restart the container β all images deleted!
- Config Changes Lost: You edit nginx.conf inside a container β restart it β back to default settings!
- Session Data Lost: User login sessions stored inside container β container crashes β all users logged out!
β The Solution β Docker Volumes
Docker Volumes store data OUTSIDE the container on the host machine. Data lives independently of the container lifecycle β even if you delete, recreate, or update your container, the data remains safe.
β Golden Rule
Always use volumes for any data you care about β especiallydatabases, user uploads, configuration files, and logs.
2π§ Easy Analogy β Hotel Room & Locker
Let's make this super easy to understand with a real-world analogy before touching any commands.
Hotel Room = Container
You check into a hotel room (start a container). When you check out (delete the container), the hotel staff cleans everything β all your stuff is gone!
Hotel Locker = Named Volume
The hotel has a personal locker (Docker Volume) for your valuables. Even after you check out and check back in, your valuables are still in the locker!
Bring Your Folder = Bind Mount
You bring your own folder from home (your PC's folder) into the hotel room. Edit files in the room and they update on your PC too β live two-way sync!
π‘ Key Insight
A Docker Volume is just afolder on your host machinethat Docker manages. When you mount it into a container, the container reads/writes to that folder β data persists even after the container is gone.
3π¦ 3 Types of Docker Storage
Docker provides three different mechanisms for persisting data. Each has its own use case, advantages, and limitations.
1. Named Volumes
Fully managed by Docker. Stored in Docker's own directory. Best for production databases and persistent app data.
-v mydata:/app/data2. Bind Mounts
You specify an exact path on your host machine. Changes reflect instantly. Best for development with live code reload.
-v /home/user/app:/app3. tmpfs Mounts
Stored in host RAM. Extremely fast but lost on container stop. Best for temporary/sensitive data like tokens.
--tmpfs /app/tempπ Where is Data Stored on Host?
4π§ͺ Lab 1 β Prove Data Loss Without Volumes
Before learning how to fix the problem, let's prove the problem exists. This lab shows exactly what happens to data when a container is deleted.
β οΈ Prerequisites
Make sure Docker is installed and running. Run docker --version to verify. You need Docker 20.x or higher.
Start an Ubuntu container and create a file inside it
We will create important data inside a container without a volume
Delete the container and try to recover data
Now delete the container and see what happens to the data
β Result: Data is Gone Forever!
The file we created is completely gone after container deletion. This is exactly the problem Docker Volumes solve. Let's fix this in Lab 2!
5π§ͺ Lab 2 β Named Volumes (MySQL Persistence)
This is the most important lab. We'll run MySQL with a named volume, insert data, delete the container, recreate it, and prove the data survived!
Create a named volume for MySQL data
Run MySQL container with the volume attached
Connect to MySQL and insert data
Delete the container β data should be SAFE!
Recreate container and verify data is back!
π Success! Data Survived Container Deletion!
MySQL data persisted because it was stored in the mysql-data volume, not inside the container. This is the power of Docker Volumes!
6π§ͺ Lab 3 β Bind Mounts (Live Code Reload)
Bind mounts are perfect for development. Edit code on your local machine and changes appear instantly inside the container β no need to rebuild the image!
Create a simple Node.js app on your host machine
Run Node.js container with bind mount
Edit code on host β see it change LIVE (no rebuild!)
π‘ Windows Users β Bind Mount Path Format
On Windows: -v C:/Users/YourName/project:/app Β |Β With WSL2: -v /mnt/c/Users/YourName/project:/app
7π§ͺ Lab 4 β tmpfs Mount (RAM Storage)
tmpfs mounts store data in host RAM. Extremely fast but lost when container stops. Perfect for sensitive temporary data like session tokens or secrets.
8π§ͺ Lab 5 β Docker Compose with Volumes
In real projects, you'll use Docker Compose to manage multi-container apps. Here's how to define volumes in a docker-compose.yml file.
Create the docker-compose.yml file
Start the stack and verify volumes
9βοΈ Essential Volume Commands Reference
10π Comparison Table
| Feature | πΎ Named Volume | π Bind Mount | β‘ tmpfs |
|---|---|---|---|
| Managed by Docker | β Yes | β No | β Yes |
| Data survives restart | β Yes | β Yes | β No |
| Data survives container delete | β Yes | β Yes | β No |
| Best for Production | β Yes | β οΈ Maybe | β No |
| Best for Development | β οΈ Maybe | β Yes | β No |
| Live code reload | β No | β Yes | β No |
| Stored in RAM | β No | β No | β Yes (Fast!) |
| Easy to backup | β Yes | β Yes | β No |
| Works on all OS | β Yes | β οΈ Path varies | β Linux only |
| Shareable between containers | β Yes | β Yes | β No |
12345.png)