Why data persistence matters in Docker - Visual Breakdown

Process Flow - Why data persistence matters

Start Container

↓

Write Data Inside Container

↓

Stop Container

↓

Restart Container

↓

Is Data Still There?

No→Data Lost

Yes↓

Data Persistence Achieved

This flow shows how data written inside a container can be lost after restart unless persistence is used.

Execution Sample

Docker

docker run --name mydb -d postgres
# Write data inside container
# Stop and remove container
docker rm -f mydb
# Restart container without volume
docker run --name mydb -d postgres

This example runs a Postgres container, writes data, removes it, then restarts without volume to show data loss.

Process Table

Step	Action	Data State Inside Container	Result
1	Start container 'mydb'	Empty database	Container running
2	Write data to database	Data saved inside container filesystem	Data present
3	Stop and remove container	Container filesystem deleted	Container stopped and removed
4	Restart container without volume	Fresh empty database	No previous data found
5	Check data presence	No data	Data lost because container storage is ephemeral

💡 Data lost after container removal because container storage is temporary without volumes

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
Data inside container	None	Present	Deleted	None	None

Key Moments - 2 Insights

Why does data disappear after restarting the container?

Because container storage is temporary and deleted when container is removed, as shown in execution_table step 3 and 4.

How can we keep data safe even if the container is removed?

By using Docker volumes or bind mounts to store data outside the container filesystem, preventing data loss.

Visual Quiz - 3 Questions

Look at the execution table, what is the data state inside the container after step 3?

A Data is still present

B Data is deleted

C Data is partially present

D Data is backed up

💡 Hint

Check the 'Data State Inside Container' column at step 3 in the execution_table

At which step does the container get removed, causing data loss?

A Step 3

B Step 2

C Step 1

D Step 5

💡 Hint

Look for the action 'Stop and remove container' in the execution_table

If we add a Docker volume, how would the data state change after step 4?

A Data would be partially lost

B Data would still be deleted

C Data would be preserved

D Container would not start

💡 Hint

Recall the explanation in key_moments about using volumes to keep data safe

Concept Snapshot

Docker containers have temporary storage.
Data written inside is lost if container is removed.
Use Docker volumes or bind mounts to keep data safe.
Volumes store data outside container lifecycle.
This ensures data persistence across restarts.

Full Transcript

When you run a Docker container and write data inside it, that data is stored in the container's own filesystem. However, this storage is temporary. If you stop and remove the container, all data inside it is deleted. When you restart a new container without any special setup, it starts fresh with no previous data. This means your data is lost. To keep data safe even if containers are removed or restarted, Docker provides volumes or bind mounts. These store data outside the container's filesystem, so data persists independently of the container lifecycle. This is why data persistence matters in Docker.

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