Why data persistence matters in Docker - Why It Works

Introduction

When you run applications in containers, any data created inside the container disappears when the container stops. Data persistence means saving data outside the container so it stays safe even if the container is removed or restarted.

When you want to keep your database data safe even if the database container stops or is deleted

When you run a web app that lets users upload files and you want those files to stay available

When you need to save logs or reports generated by a container for later review

When you want to share data between multiple containers running on the same host

When you want to upgrade or replace containers without losing important data

Config File - docker-compose.yml

docker-compose.yml

version: '3.8'
services:
  my-db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: examplepass
      MYSQL_DATABASE: mydatabase
    volumes:
      - db-data:/var/lib/mysql
volumes:
  db-data: {}

This file defines a MySQL database container with a volume named db-data. The volume stores the database files outside the container's writable layer, so data persists even if the container is removed or recreated.

The volumes section at the bottom declares the named volume db-data. The volumes key under the service maps this volume to the container's data directory /var/lib/mysql.

Commands

This command starts the MySQL container in detached mode using the docker-compose.yml file. It creates the volume automatically if it does not exist.

Terminal

docker-compose up -d

Expected Output

Creating network "default" with the default driver

Creating volume "db-data" with default driver

Creating my-db ... done

→

-d - Run containers in the background (detached mode)

This command lists all Docker volumes on the host to verify that the volume for data persistence was created.

Terminal

docker volume ls

Expected Output

DRIVER    VOLUME NAME

driver    db-data

This command stops and removes the containers but keeps the volume intact, so data is not lost.

Terminal

docker-compose down

Expected Output

Stopping my-db ... done

Removing my-db ... done

Removing network default

Starting the container again will reuse the existing volume, so the database data remains available.

Terminal

docker-compose up -d

Expected Output

Creating network "default" with the default driver

Creating my-db ... done

→

-d - Run containers in the background (detached mode)

Key Concept

If you remember nothing else from this pattern, remember: storing data outside containers keeps it safe when containers stop or are replaced.

Common Mistakes

Not using volumes and storing data only inside containers

Data will be lost when the container is removed or crashes, causing loss of important information.

Always use Docker volumes or bind mounts to save data outside the container's writable layer.

Removing volumes when stopping containers

Deleting volumes deletes all stored data, defeating persistence.

Use 'docker-compose down' without the '-v' flag to keep volumes intact.

Summary

Use Docker volumes to save data outside containers for persistence.

Start containers with volumes to keep data safe across restarts and removals.

Stopping containers without deleting volumes preserves your data.

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