DEV Community

Yash Sonawane
Yash Sonawane

Posted on

🛳️ Docker Series: Episode 6 — Docker Volumes: The Secret to Saving Your Data

#docker #productivity #beginners #tutorial

🎬 "Ever wondered why your app’s data disappears when you stop a container? In this episode, we uncover Docker Volumes — your key to persistent, reliable, and sharable data storage."

🧠 Why Data Disappears in Docker

By default, Docker containers are ephemeral — which means:

  • When the container stops, its filesystem is wiped.
  • All your app logs, databases, and uploads? Gone. 🫠

This is great for clean environments… but not if you need data to stick around.

Enter: Docker Volumes.

📦 What Is a Docker Volume?

A volume is a special folder outside the container, managed by Docker.

Think of it like:

  • A USB drive you plug into your container
  • When the container is deleted, the USB (volume) stays intact

You can re-attach it, share it across containers, and even back it up.

🔧 Using Volumes in Real Projects

🧪 Example 1: MySQL Database Persistence 

docker run -d \
  --name mysql \
  -e MYSQL_ROOT_PASSWORD=mysecret \
  -v mysql-data:/var/lib/mysql \
  mysql:latest
Enter fullscreen mode Exit fullscreen mode

✅ This creates a volume mysql-data that stores the DB.
Even if you delete the container, the database stays.

🔨 Common Volume Commands

📁 List Volumes 

docker volume ls
Enter fullscreen mode Exit fullscreen mode

🔍 Inspect a Volume 

docker volume inspect mysql-data
Enter fullscreen mode Exit fullscreen mode

❌ Remove a Volume 

docker volume rm mysql-data
Enter fullscreen mode Exit fullscreen mode

🧹 Prune Unused Volumes 

docker volume prune
Enter fullscreen mode Exit fullscreen mode

🧱 Volume Types (Simplified)

Type Use Case
Named Volume Long-term data (MySQL, logs, uploads)
Bind Mount Dev mode (sync local folders)

🧪 Example 2: Dev Sync with Bind Mount 

docker run -d \
  -v $(pwd):/app \
  -w /app \
  node:18 \
  npm start
Enter fullscreen mode Exit fullscreen mode

✅ Any change you make locally reflects inside the container in real-time.

🛠️ Tips for Volume Mastery

  • Use named volumes in production
  • Use bind mounts for live development
  • Clean up unused volumes regularly

📦 Up Next: Docker Networking Demystified

In Episode 7, we’ll explore:

  • How containers talk to each other
  • Networks, bridges, ports, and real examples (Node + DB)

💬 Let’s Talk

Did you try volumes in your app yet? Still confused between named volumes and mounts?

Drop a question — I’d love to help you debug or design the best volume setup.

❤️ If this episode helped keep your data safe, give it a like or share it with someone building with Docker.

🎬 Next: “Docker Networking — How Containers Talk Behind the Scenes”

Top comments (3)

Collapse
 
scsoi profile image
疏影 •

Thanks for the detailed reply. The three production pitfalls we hit hardest were: (1) named volumes over anonymous for anything you actually care about, (2) backup volumes before docker compose down, (3) volume drivers that hit cloud storage (like CloudStor or a NAS mount) for cross-host portability. Production patterns definitely deserve their own episode.

Collapse
 
scsoi profile image
疏影 •

Docker volumes is one of those topics where the basics are easy and the production pitfalls are where teams lose data. Three patterns that bit us:

  1. Anonymous volumes from Dockerfiles — any VOLUME directive in a Dockerfile creates an anonymous volume at run time if no mount is specified. They take space, they do not get cleaned up on docker rm -v, and they silently accumulate. Always specify a named volume or bind mount.

  2. Volume drivers vs local volumes — local is the default and is fastest, but it ties the volume to that one Docker host. For multi-host (Swarm, K8s) or HA setups, you need a network volume driver (NFS, CephFS, EBS, S3-based). The driver choice locks you in early; pick before you start shipping data.

  3. Backup strategy for volumes — bind mounts are easy to backup with standard tools (rsync, snapshot). Named volumes require docker run --rm --volumes-from to access from a backup container. For ops access on Windows workstations, drive-letter mount of the underlying NAS or EBS volume is the cleanest approach to scriptable backups.

Mount layer for ops browsing named volume data: ScsDriver

Collapse
 
yash_sonawane25 profile image
Yash Sonawane •

Great points! I completely agree that the basics of Docker Volumes are easy, but the production pitfalls are where things get really interesting.

The points about anonymous volumes, volume drivers, and backup strategies are especially important. I focused this episode on the fundamentals for beginners, but these are exactly the kinds of considerations engineers need to understand before using volumes in production.

I’ll definitely cover these deeper production patterns in a future episode. Thanks for adding such valuable real-world insights to the discussion!