The platform works. curl http://localhost:3000/books returns the eight titles and the site loads in the browser. But there is a crack in the foundations that you have already tripped over twice without paying attention: every time you recreate aurora-db, the catalog disappears and you have to load init.sql by hand again with docker cp. On a development machine that is an annoyance. On the server holding a real bookshop's catalog, it is a catastrophe.

This lesson solves containers' second big problem, after networking: data. You are going to demonstrate the loss with an experiment that is a little frightening, you are going to learn the three types of mount Docker offers and when to use each one, you are going to understand where volumes really live and why you should not touch them by hand, and you are going to give PostgreSQL a named volume so that the Aurora Libros catalog survives the destruction of its container. At the end you will repeat the opening experiment and the result will be the opposite.

1. The problem, demonstrated
2. The three types of mount
3. Docker-managed volumes
4. Anonymous volumes and the orphan problem
5. Bind mounts: files from your machine inside the container
6. -v versus --mount
7. Read-only mounts
8. tmpfs: data in memory
9. Hands-on: aurora-data and the destruction test
10. Backup and restore
11. Best practices

Let's start by looking the disaster in the face. Add a new book to the catalog:

Nine books. The API serves them. Now simulate what happens in any normal operation: updating the PostgreSQL image, changing an environment variable, adding a memory limit... all of that forces you to recreate the container, as you have known since lesson 03-01.

It is not that El Aleph is missing: the table no longer exists. The whole Aurora Libros catalog has evaporated. And the API, consistently:

This is not a Docker bug: it is Docker's design, and you already knew it from lesson 01-05. A container writes to a writable layer that is born with it and dies with it. The nine rows were in an anonymous volume that Docker created automatically —you discovered it in exercise 2 of lesson 03-03— and which, when the container was recreated, was replaced by a new, empty one.

The solution is to take the data out of the container. Let's get to it.

Docker offers three ways for a path inside the container to point at something that is not in its writable layer:

The decision rule, in one sentence: if the data matters and the application manages it, a volume; if the file is yours and you want to edit it from your editor, a bind mount; if it must never touch disk, tmpfs.

That second unreadable name is an orphaned anonymous volume, left over from one of the aurora-db containers you have deleted. We will come back to it.

Mountpoint is the path on the host. And here comes the most important warning of this section:

Do not go in there and touch files. That path is the Docker daemon's property: it belongs to root, its permissions and its security context are managed by Docker, and on Docker Desktop (macOS and Windows) it does not even exist on your machine, but inside a Linux virtual machine you have no direct access to. Writing there by hand is an excellent way to corrupt a database.

The correct way to look inside a volume is with a container:

Empty, freshly created. This pattern —an ephemeral Alpine container that mounts the volume— is the Swiss army knife for inspecting, copying and restoring volumes, and you will use it in section 10.

Just as with containers, labeling lets you clean up selectively:

An anonymous volume is one Docker creates on its own, without you asking, in two situations:

1. When the image declares VOLUME /path in its Dockerfile (postgres, redis, mysql, mongo… all do).
2. When you mount with -v /path giving only the destination, with no source.

That 64-character name is the anonymous volume. And here is its problem:

The volume is still there, orphaned. With no container using it, with a name nobody can remember, and taking up disk indefinitely. Every postgres you have deleted in this module left one of these behind, with its data inside, unrecoverable in practice.

Clean up the orphans now, checking first what you are about to take down:

Careful with this command: docker volume prune deletes real data and there is no recycle bin. An "unused" volume may belong to a database whose container is simply stopped. Since Docker 23, prune only touches anonymous ones by default; to include named ones you need --all, which is a safety net worth not disabling lightly.

A bind mount connects a specific path on your host with a path in the container. You already used it in lesson 01-06 with your index.html.

It is the same file seen from two places: changes flow in both directions and in real time. That is its superpower for development —you edit in your IDE and the container sees it instantly— and its danger in production.

Rules and traps:

This is the classic bind mount headache:

In this case it works by coincidence: your host user has UID 1000 and the image's node user does too. But try it with a different user:

The kernel compares numbers, not names. Inside the container there is no such thing as a "host user": there are only UIDs and GIDs, and the file's permissions are whatever they are on your machine. The three usual solutions:

And from that comes a rule worth memorizing: bind mounts are for development and configuration files; production data goes in volumes.

Docker offers two syntaxes for the same thing:

That "if the source does not exist" is the most important practical difference. With -v, a typo in the path leaves you with an empty directory and a container that starts without its data; with --mount, you get a clear error and the container does not start.

An equivalence table to keep at hand:

src and source are synonyms, as are dst, destination and target.

A configuration file has no business being writable by the container. Marking it read-only is a cheap and effective defense:

The kernel prevents it, not Docker. It is the same mechanism you used with index.html and nginx.conf in the previous lesson. Use it whenever you mount:

• Configuration files (nginx.conf, redis.conf, postgresql.conf).
• Initialization scripts (init.sql).
• Certificates and public keys.
• Static content the application must not modify.

A tmpfs mount creates a file system in the host's RAM. Nothing touches disk and everything disappears when the container stops:

Real use cases: secrets decrypted at runtime, session files, temporary directories for applications running with a read-only root file system, and any data that by regulation must not be written to disk. It only works on Linux.

It is time to fix aurora-db once and for all.

The second row uses a convention of the official PostgreSQL image: everything in /docker-entrypoint-initdb.d/ (.sql, .sql.gz or .sh files) is run automatically, in alphabetical order, the first time the database is initialized. It is exactly the job you have been doing by hand with docker cp for two lessons.

The chmod 644 is not decorative: the PostgreSQL process runs as the postgres user (UID 70), and if the file were readable only by your user, the script could not run. It is the UID clash from section 5, applied.

Check what happened at startup:

The eight books loaded themselves. No docker cp, no psql -f, nothing to remember.

Verify the mounts:

A writable volume for the data and a read-only bind mount for the script. Exactly the plan.

Add El Aleph again:

And now, destroy the container. Without fear:

The container no longer exists. The volume is still there. Recreate it with exactly the same command as before:

El Aleph is still there. You have completely deleted the database container and the catalog has survived intact, with its nine books. Compare with section 1 of this very lesson, where the same experiment destroyed even the table.

And there is a detail in the logs worth a look:

init.sql did not run again. The image detects that the data directory already contains a database and skips initialization. That is exactly what you want: if it ran every time, the CREATE TABLE IF NOT EXISTS would do no harm, but a less careful script could wipe real data on every start. And the practical consequence: if you change init.sql, restarting will not be enough; you will have to delete the volume for it to initialize from scratch again.

(Do not run it now: you need it for the next lesson.)

The Nginx container you created in the previous lesson already uses bind mounts; now you can read that command with new eyes:

Read-only bind mounts for two files that live in your Git repository. Edit index.html in your editor, reload the browser, and the change is there without rebuilding any image: that is the development workflow that becomes the star of lesson 04-07.

A volume that is not backed up is a volume that will be lost. There are two strategies and they serve different purposes.

The universal pattern: an ephemeral container that mounts the volume and a host directory, and runs tar.

What each part does:

Restoring is the reverse operation:

The ..?* in the rm is there to include hidden files; without it, leftovers from the previous installation would end up mixed in with the backup.

For a database, a logical backup is almost always better: a SQL file with the schema and the data.

And restoring it, with -i so that psql reads from standard input:

A comparison of the two strategies:

The rule: use the service's native tool if it has one (pg_dump, mysqldump, redis-cli BGSAVE), and the container-with-tar trick for everything else.

The current state of Aurora Libros's storage:

A single named volume, and 0 B reclaimable: not one orphan. That is the goal.

What this lesson does not cover and where you will see it: the daemon's storage drivers (overlay2 and friends), the volume drivers for NFS, SMB or cloud storage, and the advanced performance options are studied in lesson 05-02. How volumes are declared in a compose.yaml file, in lesson 04-02.

• Trusting the writable layer for data that matters. It dies with the container, and recreating a container is a routine operation.
• Using anonymous volumes without knowing it. Every image with VOLUME in its Dockerfile creates one. If you do not give it a name, your data depends on a hash nobody remembers.
• Running docker volume prune without looking. It deletes real data with no second confirmation and no recycle bin. List first with docker volume ls -f dangling=true.
• Writing by hand in /var/lib/docker/volumes/.... Wrong permissions, corruption, and on Docker Desktop that path does not even exist.
• Relative paths in a bind mount. Use absolute paths or $(pwd); with -v, a misspelled path turns into an empty directory created as root.
• Mounting an empty directory over one that had content. The mount hides what came from the image: Nginx will return 403 and PostgreSQL will reinitialize.
• Expecting init.sql to run on every start. It only runs when the data directory is empty. If you change it, delete the volume.
• Backing up a database volume hot with tar. It can come out corrupt. Stop the container, or use pg_dump.
• Tip: write the docker run for your services with data in a notes file. It is long and you have to reproduce it exactly so as not to lose the volume... until module 4, where that is solved for good.
• Tip: name your backups with the date and automate their rotation. And restore at least once, so you know it works.

Create an alpine:3.20 container called three-mounts with sleep 600 and three mounts at once: a named volume test-vol at /vol, a bind mount of ~/aurora-libros/tests at /bind, and an 8 MB tmpfs at /mem. Write a different file in each path. Then:

1. Restart the container with docker restart and check which of the three files remain.
2. Delete it with docker rm -f (without -v), create a new one with the same mounts and check all three again.
3. Explain the results and say which mount you would use for: the book catalog, the nginx.conf, and a session token that must not touch disk.

Redis stores its snapshot in /data, which the official image declares as a VOLUME and which is therefore an anonymous volume today. Fix that:

1. Check with docker inspect that the current aurora-cache uses an anonymous volume.
2. Recreate it with a named volume aurora-cache-data and with persistence enabled via the command redis-server --appendonly yes.
3. Write a key, force a save, destroy the container and recreate it. Check whether the key survives.
4. Answer: does it make sense to persist a cache? Argue for and against.

With the platform working and the nine books in place:

1. Make a logical backup with pg_dump and a physical one with tar, noting the size of each.
2. Cause the disaster: delete the aurora-db container and the aurora-data volume.
3. Check what the API answers at that moment.
4. Recover by the fastest route and explain which one you chose and why. Verify that the nine books —including El Aleph, which is not in init.sql— are available again through curl http://localhost:8080/api/books.

Solution to exercise 1

1. After docker restart:

The tmpfs has already been lost with a simple restart: it lived in RAM and the mount is recreated empty on every start.

2. After deleting and recreating:

3. Results and decisions:

And the three decisions: the book catalog → a named volume (production data that must survive and whose permissions Docker manages); the nginx.conf → a read-only bind mount (a file versioned in Git that you want to edit in your IDE and that the container only reads); the session token → tmpfs (it must not be written to disk even for an instant, and it must evaporate when the container stops).

Solution to exercise 2

Anonymous volume confirmed: a 64-character name, created by the VOLUME /data in Redis's official Dockerfile.

The key survives. Note that two things were needed: the named volume (so the files persist) and --appendonly yes (so Redis writes to them). A volume with persistence disabled would store a file that never gets updated.

4. Does it make sense to persist a cache?

In favor:

• A warm start. After a restart, the cache already has data and there is no avalanche of requests against PostgreSQL (the phenomenon known as the thundering herd).
• If Redis is also used for user sessions or job queues, then it is no longer a cache: it is data whose loss has visible consequences.

Against:

• A cache, by definition, must be losable without consequences. If your system does not work without it, it is not a cache: it is a database in disguise, and it should be treated as one.
• Persistence costs: disk I/O on every write and a slower startup.
• Persisted data can become stale: on recovery, Redis serves an old catalog until the TTL expires.

For Aurora Libros, with a 60-second TTL and a small catalog, it is not worth it: it is cleaner to leave aurora-cache without persistence and let it refill itself on the first request. That is the criterion that will be applied in module 4's compose.yaml.

Solution to exercise 3

1. The two backups:

The logical one is two thousand times smaller than the physical one, for exactly the same nine books.

2 and 3. The disaster:

Interesting: the error is not a database one, but a DNS one. Since the container does not exist, the name aurora-db does not resolve on aurora-net. It is the same ENOTFOUND from lesson 03-04, now with a different cause: there the network was missing, here the container is.

4. The recovery:

Eight, not nine. init.sql restored the original catalog, but El Aleph is not there: it was inserted afterwards. This is where the backup stops being a formality and becomes the only thing that saves you:

I chose the logical backup, for three reasons:

1. It is faster to apply: a 4 kB psql versus stopping the service, emptying the volume and unpacking 8.4 MB.
2. It requires stopping nothing: it restores onto the running database, while the physical backup forces you to stop the container.
3. It is portable: if while recovering I had taken the chance to move up to PostgreSQL 17, the volume's tar would have been useless —the data directory's format is specific to each major version— and the .sql would not.

The physical backup still has its role: it is the only option for volumes of applications that have no dump tool of their own, and it is a bit-for-bit copy including configuration and state that pg_dump does not capture.

The second big problem is solved. You have seen with your own eyes that a destroyed container takes its data with it —the first time not even the books table was left— and you know why: the writable layer is born and dies with the container, and the anonymous volumes that images like postgres or redis create on their own are not reused, but left orphaned with their data inside, unreachable in practice.

You know the three types of mount and when to use each one: Docker-managed volumes for data that matters, bind mounts for configuration and development, and tmpfs for whatever must not touch disk. You know where volumes really live —/var/lib/docker/volumes/…, the daemon's territory, invisible on Docker Desktop— and that the correct way to look inside is an ephemeral Alpine container, never your editor. You understand bind mounts' UID clash, because the kernel compares numbers and not names, and you have the three ways of resolving it. And you prefer --mount over -v in scripts for one very specific reason: it fails loudly instead of creating an empty directory that silently ruins the startup.

Aurora Libros has changed category. aurora-db keeps its state in the named volume aurora-data and receives init.sql as a read-only bind mount at /docker-entrypoint-initdb.d/, so the catalog loads itself the first time and is never overwritten again. The definitive test came out as it should: you inserted El Aleph, destroyed the entire container, recreated it with the same command and the nine books were still there. And aurora-web serves index.html and nginx.conf from your repository in :ro, editable from your IDE without rebuilding anything. On top of that you know how to back up and restore: with a helper container and tar for any volume, and with pg_dump —smaller, hot and portable between versions— for the database.

Two risks remain standing, and they are the last of this module. You saw the first in docker stats in lesson 03-04: none of your containers has a memory limit, so a runaway query in PostgreSQL or a leak in Node can leave the whole machine out of RAM. The second is that if a container dies at three in the morning, nobody brings it back up. In the next lesson, Resource Limits and Restart Policies, you will close in on both: memory and CPU limits with their tables of combinations, the OOM killer triggered on purpose so you can see it with OOMKilled: true and its code 137, --pids-limit as a defense against a fork bomb, and the four restart policies with the subtle difference between always and unless-stopped. And by the end, you will have in front of you the complete list of commands needed to bring up Aurora Libros from scratch... and you will understand why Docker Compose exists.