Manage Data in Docker
Docker containers come and go. Your data should not.
we discuss three common ways Docker handles data: volumes, bind mounts, and tmpfs. Each has a purpose, and each can hurt you in a different way if you use it carelessly.
1) Docker Volumes
Volumes are the default choice for persistence because Docker manages them and keeps the details out of your way.
On Linux, volumes typically live under
/var/lib/docker/volumes.
Volumes usually survive even when containers get deleted.
Check available volume commands
docker volume --help
Common volume actions:
| Command | Description |
| create | Create a new volume |
| inspect | Show volume metadata |
| ls | List volumes |
| prune | Remove unused volumes |
| rm | Remove specific volumes |
List volumes
docker volume ls
DRIVER VOLUME NAME
local 3c07a7016efd601c09bc15e1894a29924452c0651bc06a8470e8d3f448ca4f64
local b8be02b6005ca1c09603b43127faec8db6f20a09c1e2eaf5c4f73d146c178372
On a clean machine, the list may be empty. After you run a few containers, Docker starts leaving volume artifacts around.
Create a volume
docker volume create demo
docker volume ls
DRIVER VOLUME NAME
local 3c07a7016efd601c09bc15e1894a29924452c0651bc06a8470e8d3f448ca4f64
local b8be02b6005ca1c09603b43127faec8db6f20a09c1e2eaf5c4f73d146c178372
local demo
Inspect the host-side location:
raj@raj-ubuntu:~$ sudo ls /var/lib/docker/volumes
[sudo] password for raj:
3c07a7016efd601c09bc15e1894a29924452c0651bc06a8470e8d3f448ca4f64 b8be02b6005ca1c09603b43127faec8db6f20a09c1e2eaf5c4f73d146c178372 backingFsBlockDev demo metadata.db
Test volume persistence
Run a container and mount the volume at /opt:
raj@raj-ubuntu:~$ docker run \
--name kali-test \
-d -v demo:/opt -it my-kali-fullv:lab
038471b28be7ce5a99a1c6d7f50b2d8956fe0059e14f94a4c58efe07b396dfeb
Enter the container and write a file into /opt:
raj@raj-ubuntu:~$ docker exec -it kali-test bash
┌──(root㉿038471b28be7)-[/]
└─# whoami
root
┌──(root㉿038471b28be7)-[/]
└─# ls
bin boot dev etc home lib lib32 lib64 media mnt opt proc root run sbin srv sys tmp usr var
┌──(root㉿038471b28be7)-[/]
└─# echo "docker volume testing" > /opt/volume_testing.txt
┌──(root㉿038471b28be7)-[/]
└─# exit
exit
Now check the volume data on the host. The file should be there:
raj@raj-ubuntu:~$ sudo ls /var/lib/docker/volumes/demo/_data
microsoft volume_testing.txt
That is the whole point: the data lives with the volume, not with the container.
Reuse the same volume in another container
docker run --name kali-test2 -d -v demo:/tmp -it my-kali-fullv:lab bash
ba5dddf288432ee65e86ba80fcb9333b21bc2d8c3ceb4bf5ab7efbbe3bd73979
raj@raj-ubuntu:~$ docker exec kali-test2 ls /tmp
microsoft
volume_testing.txt
Volumes exist outside the container lifecycle, so multiple containers can read and write the same data.
Visual summary
2) Bind Mounts
Bind mounts map an exact host path into the container.
Docker does not manage bind mount content.
The container sees whatever is on the host, and the host sees whatever the container writes.
Host folder example:
raj@raj-ubuntu:~$ cd kali-lab-docker/
raj@raj-ubuntu:~/kali-lab-docker$ ls
setup-kali.sh uname.txt
Run a container with a bind mount to /opt:
raj@raj-ubuntu:~/kali-lab-docker$ docker run --name kali-test3 -d -v ~/kali-lab-docker:/opt -it my-kali-fullv:lab
31f18e17d09b9753b107cc2048a7395d1841834083e12fe0a94f18b353ff673f
raj@raj-ubuntu:~/kali-lab-docker$ docker exec -it kali-test3 bash
──(root㉿31f18e17d09b)-[/opt]
└─# ls
setup-kali.sh uname.txt
If you create a file inside /opt in the container, it shows up on the host. If you delete a file in the container, it disappears on the host too.
Bind mounts directly change host files.
That is useful in dev, risky everywhere else.
Illustration
When to use bind mounts
Local development (source code, configs, quick iteration)
Sharing artifacts between host tools and a container
Avoid in production unless you have a strong reason and strong guardrails.
3) tmpfs Mounts
tmpfs mounts keep data in RAM only.
Fast
Temporary
Gone when the container stops
Use cases: sensitive material, short-lived caches, scratch space.
Example:
docker run -d --name temp --tmpfs /cache ubuntu:20.04
Volume cleanup
Docker loves to collect volumes like humans collect unread emails.
Remove unused volumes
This deletes volumes that are not referenced by any container:
docker volume prune
It prompts you. Press y if you actually want them gone.
Remove a specific volume
If you are sure the volume is not needed:
docker volume rm demo
If Docker refuses, a container (even a stopped one) is still holding a reference. Remove the container first, then retry.
