Why data persistence matters in Docker - See It in Action

Why Data Persistence Matters with Docker

📖 Scenario: Imagine you are running a simple web application inside a Docker container. You want to save user data so it is not lost when the container stops or is removed.

🎯 Goal: Learn how to create a Docker container with a volume to keep data persistent even after the container is deleted.

📋 What You'll Learn

Create a Docker volume named user_data

Run a Docker container named my_app using the busybox image

Mount the user_data volume to /data inside the container

Write a file inside the container's /data directory

Verify the file persists after container removal

💡 Why This Matters

🌍 Real World

Data persistence is critical for applications like databases, web servers, and any service that needs to keep user data safe even if containers restart or are deleted.

💼 Career

Understanding Docker volumes and data persistence is essential for DevOps roles to manage containerized applications reliably in production environments.

1

Create a Docker volume

Create a Docker volume called user_data to store data persistently outside containers.

Docker

# Create the Docker volume user_data
# Your code here

Hint

Use the docker volume create command followed by the volume name.

2

Run a container with the volume mounted

Run a Docker container named my_app using the busybox image. Mount the user_data volume to the container's /data directory.

Docker

docker volume create user_data
# Run the container my_app with user_data volume mounted at /data
# Your code here

Hint

Use docker run -dit --name my_app -v user_data:/data busybox to start the container.

3

Write data inside the container

Use docker exec to write the text Hello, persistent world! into a file named /data/message.txt inside the my_app container.

Docker

docker volume create user_data
docker run -dit --name my_app -v user_data:/data busybox
# Write the message to /data/message.txt inside my_app
# Your code here

Hint

Use docker exec my_app sh -c "echo 'Hello, persistent world!' > /data/message.txt" to write the file.

4

Verify data persistence after container removal

Stop and remove the my_app container. Then run a new container named my_app2 with the same user_data volume mounted at /data. Use docker exec to display the contents of /data/message.txt inside my_app2.

Docker

docker volume create user_data
docker run -dit --name my_app -v user_data:/data busybox
docker exec my_app sh -c "echo 'Hello, persistent world!' > /data/message.txt"
# Stop and remove my_app, then run my_app2 with the same volume
# Display the contents of /data/message.txt inside my_app2
# Your code here

Hint

Use docker stop my_app and docker rm my_app to remove the first container. Then run docker run -dit --name my_app2 -v user_data:/data busybox and docker exec my_app2 cat /data/message.txt to verify the file content.

Practice

1. Why is data persistence important when using Docker containers?

easy

A. Because containers automatically save data to the host system

B. Because data persistence makes containers run faster

C. Because Docker containers never delete data inside them

D. Because containers are temporary and data is lost when they stop

Solution

1. Step 1: Understand container lifecycle

   Docker containers are designed to be temporary and can be stopped or removed easily.

2. Step 2: Recognize data loss risk

   When a container stops or is deleted, any data stored inside it is lost unless persisted externally.

3. Final Answer:

   Because containers are temporary and data is lost when they stop -> Option D

4. Quick Check:

   Temporary containers lose data without persistence [OK]

Hint: Remember: containers reset, so save data outside [OK]

Common Mistakes:

• Thinking containers save data automatically
• Assuming data inside container is permanent
• Confusing persistence with performance

2. Which Docker command option is used to create a persistent data volume?

easy

A. docker run -v /host/path:/container/path

B. docker run --rm

C. docker run --network=host

D. docker run --memory=512m

Solution

1. Step 1: Identify volume option

   The -v or --volume flag maps a host directory to a container directory for persistence.

2. Step 2: Check other options

   --rm removes container after exit, --network=host sets network mode, --memory limits memory; none create persistent storage.

3. Final Answer:

   docker run -v /host/path:/container/path -> Option A

4. Quick Check:

   Volume flag = -v [OK]

Hint: Use -v to link host folder for persistence [OK]

Common Mistakes:

• Using --rm which deletes container and data
• Confusing network or memory flags with storage
• Not specifying host path in volume mapping

3. What will happen if you run this command twice without a volume?

docker run --rm alpine sh -c "echo hello > /tmp/file.txt"

medium

A. The file will be lost after the container stops

B. The file will be saved on the host automatically

C. The container will fail to start the second time

D. The file will persist and contain 'hello' after both runs

Solution

1. Step 1: Analyze container data storage

   Without a volume, data inside the container is stored in the container's writable layer, which is deleted when container is removed.

2. Step 2: Consider container restart

   Running the command twice creates new containers or overwrites existing ones, losing previous data inside.

3. Final Answer:

   The file will be lost after the container stops -> Option A

4. Quick Check:

   No volume means no data persistence [OK]

Hint: No volume means data lost on container stop [OK]

Common Mistakes:

• Assuming data inside container persists automatically
• Thinking container names prevent data loss
• Believing host saves container files without volume

4. You want to persist data but your Docker container loses files after restart. What is the most likely mistake?

medium

A. You used --rm flag when running the container

B. All of the above

C. You mapped a volume but to a wrong host directory

D. You forgot to map a volume with -v option

Solution

1. Step 1: Check volume mapping

   Not using -v means no data persistence outside container.

2. Step 2: Consider container removal flags and paths

   --rm deletes container and data on exit; wrong host path means data saved elsewhere.

3. Final Answer:

   All of the above -> Option B

4. Quick Check:

   Missing or wrong volume or --rm causes data loss [OK]

Hint: Check volume and flags carefully to keep data [OK]

Common Mistakes:

• Ignoring --rm deletes container and data
• Mapping volume to wrong or non-existent host path
• Assuming volume mapping alone guarantees persistence

5. You have a Docker container that writes logs to /app/logs. How do you ensure logs persist on the host even if the container is removed?

hard

A. Copy logs manually after container stops

B. Run the container with docker run --rm

C. Run the container with docker run -v /host/logs:/app/logs

D. Use docker commit to save container state

Solution

1. Step 1: Map container logs directory to host

   Using -v /host/logs:/app/logs links container logs to host folder for persistence.

2. Step 2: Avoid temporary container flags

   --rm deletes container and logs; copying manually is error-prone; docker commit saves image, not files.

3. Final Answer:

   Run the container with docker run -v /host/logs:/app/logs -> Option C

4. Quick Check:

   Volume mapping keeps logs safe [OK]

Hint: Map logs folder with -v for safe persistence [OK]

Common Mistakes:

• Using --rm deletes container and logs
• Relying on manual copying which is error-prone
• Misunderstanding docker commit saves files