How to Manage Persistent Data in Docker Using Named Volumes, Bind Mounts, and Tmpfs Mounts

ByAkensai

Understanding how to manage persistent data in Docker using named volumes, bind mounts, and tmpfs mounts is one of the most important skills for any server administrator. By default, Docker containers are stateless. When a container stops or gets removed, all data inside it disappears. That’s a problem for databases, WordPress sites, and any application that needs to keep its data between restarts. This tutorial walks you through all three Docker storage options. You’ll learn when to use each one, how to create them, and how to attach them to containers. Whether you’re running a MySQL database or a simple web server, this guide gives you the practical knowledge to keep your data safe.

Prerequisites and Requirements for Managing Docker Persistent Data

Before you start, make sure you have the following in place.

Required software:

  • Docker Engine installed on a Linux server (Ubuntu 20.04 or 22.04 recommended)
  • Docker Compose (optional but helpful)
  • A user account with sudo privileges

Assumed knowledge:

  • Basic Linux command-line usage
  • Familiarity with running Docker containers
  • Understanding of file permissions in Linux

Estimated time: 30–45 minutes

If you don’t have Docker installed yet, follow the official Docker Engine installation guide for Ubuntu before continuing.

You should also know the difference between the three storage types at a high level. Named volumes are managed entirely by Docker. Bind mounts link a host directory directly into a container. Tmpfs mounts store data in memory only. Each has a specific use case, and you’ll cover all three in the steps below.

Step-by-Step Guide to Using Named Volumes, Bind Mounts, and Tmpfs Mounts

For a related walkthrough, see: How to Install Proxmox on Ubuntu

This section covers how to manage persistent data in Docker using named volumes, bind mounts, and tmpfs mounts through hands-on examples.

Step 1: Create and use a named volume

Named volumes are the recommended way to persist data in Docker. Docker manages the storage location on the host automatically.

Run this command to create a named volume:

docker volume create myapp_data

Verify it was created:

docker volume ls

Now attach it to a container. This example uses a MySQL container:

docker run -d 
  --name mysql_db 
  -e MYSQL_ROOT_PASSWORD=securepassword 
  -e MYSQL_DATABASE=mydb 
  -v myapp_data:/var/lib/mysql 
  mysql:8.0

The -v myapp_data:/var/lib/mysql flag mounts the named volume to MySQL’s data directory. Even if you stop and remove the container, your database files stay safe inside the volume.

Step 2: Inspect and manage your named volume

Check where Docker stores the volume data on your host:

docker volume inspect myapp_data

You’ll see a Mountpoint field showing the actual path on disk, usually under /var/lib/docker/volumes/.

To remove a volume when you no longer need it:

docker volume rm myapp_data

Never remove a volume while a container is still using it. Docker will throw an error if you try.

Step 3: Set up a bind mount

Bind mounts give you direct control. You map a specific directory on your host into the container. This is great for development. You can edit files on your host and see changes instantly inside the container.

Create a directory on your host first:

mkdir -p /home/youruser/mysite

Now run a container with a bind mount:

docker run -d 
  --name wordpress_dev 
  -p 8080:80 
  -v /home/youruser/mysite:/var/www/html 
  wordpress:latest

Any file you place in /home/youruser/mysite on your host will appear inside the container at /var/www/html. This works perfectly for WordPress theme or plugin development.

Step 4: Set bind mount permissions correctly

Bind mounts can cause permission errors. The user inside the container may not match the user on your host. Check the container’s expected user ID:

docker exec wordpress_dev id www-data

If the UID doesn’t match your host files, fix it with:

sudo chown -R 33:33 /home/youruser/mysite

UID 33 is typically the www-data user in Debian-based containers. Adjust this based on your container’s output.

Step 5: Use a tmpfs mount for temporary in-memory storage

Tmpfs mounts don’t write to disk at all. They store data in RAM. Use this for sensitive or temporary data you don’t want persisted. It’s also faster than disk-based storage.

Run a container with a tmpfs mount:

docker run -d 
  --name temp_app 
  --tmpfs /app/cache:rw,size=100m 
  nginx:latest

This creates a 100MB in-memory filesystem at /app/cache inside the container. When the container stops, that data is gone permanently.

Step 6: Use volumes with Docker Compose

In production, Docker Compose makes volume management much cleaner. Here’s a practical example for a WordPress and MySQL stack:

version: '3.8'

services:
  db:
    image: mysql:8.0
    volumes:
      - db_data:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: securepassword
      MYSQL_DATABASE: wordpress

  wordpress:
    image: wordpress:latest
    ports:
      - "8080:80"
    volumes:
      - wp_/var/www/html/wp-content
    depends_on:
      - db

volumes:
  db_data:
  wp_

Save this as docker-compose.yml and run:

docker compose up -d

Docker Compose automatically creates the named volumes db_data and wp_content for you.

Step 7: Back up a named volume

Always back up your volumes before making major changes. Use a temporary container to create a tar archive:

docker run --rm 
  -v myapp_data:/data 
  -v $(pwd):/backup 
  alpine tar czf /backup/myapp_data_backup.tar.gz -C /data .

This saves a compressed backup to your current directory on the host. You can refer to the Docker volume backup documentation for more advanced restore techniques.

Troubleshooting Common Docker Storage Issues

Problem: Permission denied errors with bind mounts
This is the most common issue. The container process runs as a different user than your host files. Use chown to match UIDs as shown in Step 4. You can also add :z or :Z to the volume flag if you’re running SELinux.

Problem: Volume data not persisting after container removal
Make sure you’re using a named volume or bind mount. If you used an anonymous volume (no name assigned), Docker may clean it up. Always name your volumes explicitly.

Problem: Tmpfs mount not available
The --tmpfs flag requires Linux. It doesn’t work on Docker Desktop for Mac or Windows. Use a Linux host or a Linux VM for tmpfs support.

Problem: Can’t remove a volume
A volume in use by a container can’t be deleted. Stop and remove the container first:

docker stop container_name && docker rm container_name
docker volume rm volume_name

Warning: Running docker volume prune deletes all unused volumes. Double-check before running this in production.

Conclusion: Keeping Your Docker Data Safe

You now know how to manage persistent data in Docker using named volumes, bind mounts, and tmpfs mounts across real-world scenarios. Named volumes are best for production databases and application data. Bind mounts work well for local development and config files. Tmpfs mounts handle sensitive, short-lived data that should never touch disk.

The key takeaway is simple. Never rely on a container’s internal filesystem for data you care about. Always attach external storage from day one. Start applying these techniques to your Docker projects today. Consider combining this knowledge with Docker Compose for cleaner, more maintainable infrastructure setups.

Similar Posts