Managing Docker Volumes

What this article covers

• Why volumes matter.
• The difference between named volumes, bind mounts, and tmpfs.
• How to create, list, and delete volumes.
• How to back up and restore volumes.
• Common pitfalls and best practices.

Introduction: Managing Docker Volumes

Docker containers are stateless by default. Once a container is deleted, any data stored inside it vanishes. To preserve configurations, models, databases, and working data, you need to persist data on the host or in separate storage areas. Docker provides volumes for exactly this purpose. Understanding volumes properly helps you avoid data loss and restart containers safely.

This article walks through the most common volume types, essential commands, and backup strategies for local AI projects.

Key Terms

• Volume: Managed storage area for container data.
• Named Volume: A named volume managed by Docker.
• Bind Mount: A host directory mounted into the container.
• tmpfs Mount: Temporary storage in RAM.
• Layer: Writable layer of a container.
• Persistence: Data remains available after the container stops.
• Driver: Storage driver for volumes.

Why Volumes?

• Data persists even after containers are deleted.
• Container images stay small and portable.
• Multiple containers can share data.
• Backups and migrations become straightforward.
• Data lives outside container layers.

Types of Volumes

Named Volumes

Docker manages the storage location. Data typically lives under /var/lib/docker/volumes/.

docker volume create ollama-data

Basic usage:

docker run -d -v ollama-data:/root/.ollama ollama/ollama

Bind Mounts

A host directory is mounted into the container. The path is explicitly defined.

docker run -d -v /path/on/host:/path/in/container ollama/ollama

Good for development and when you need direct file access.

tmpfs Mounts

Data lands in RAM and is lost when the container stops. Suitable for temporary data.

docker run -d --tmpfs /tmp ollama/ollama

Volumes with docker run

docker run -d \
  --name ollama \
  -v ollama-data:/root/.ollama \
  -p 11434:11434 \
  ollama/ollama

Volumes in Compose

services:
  ollama:
    image: ollama/ollama
    volumes:
      - ollama-data:/root/.ollama

volumes:
  ollama-data:

Managing Volumes

Command	Purpose
docker volume ls	List all volumes.
docker volume create <name>	Create a volume.
docker volume inspect <name>	Show details.
docker volume rm <name>	Delete a volume.
docker volume prune	Remove unused volumes.

Backup and Restore

Backup

docker run --rm -v ollama-data:/data -v $(pwd):/backup busybox tar -czf /backup/ollama-data.tar.gz -C /data .

Restore

docker run --rm -v ollama-data:/data -v $(pwd):/backup busybox tar -xzf /backup/ollama-data.tar.gz -C /data

From a Running Container

docker exec ollama tar -czf - /root/.ollama > ollama-data.tar.gz

Migrating Volumes

Volumes can be transferred to another host:

docker run --rm -v ollama-data:/data -v $(pwd):/backup busybox tar -czf /backup/ollama-data.tar.gz -C /data .
scp ollama-data.tar.gz another-host:/path/
docker run --rm -v new-ollama-data:/data -v /path:/backup busybox tar -xzf /backup/ollama-data.tar.gz -C /data

Named Volume vs. Bind Mount

Aspect	Named Volume	Bind Mount
Management	Docker	User
Path	Internal, abstracted	Fixed host path
Portability	High	Path-dependent
Access	Less direct	Direct on host
Security	Container user adjusted	Host permissions

Best Practices

• Use named volumes for production, bind mounts for development.
• Plan volumes before starting containers.
• Run backups regularly.
• Avoid docker volume prune if important data might be present.
• Check permissions if you encounter permission denied errors.
• Give volumes meaningful names.

Common Pitfalls

• Forgetting a volume: Data is lost when the container restarts.
• Wrong container path: Data ends up in an unexpected location.
• Access rights: The container user cannot access host files.
• Volume prune: Accidentally deleting data.
• Network paths: Bind mounts on remote filesystems can cause issues.
• Multiple containers on one volume: Concurrent writes can create conflicts.

Further Reading

• BotServ.de Docker Commands
• BotServ.de Docker Compose
• BotServ.de Proxmox Backups and Restore
• BotServ.de Ollama Commands

FAQ: Docker Volumes

When should I use named volumes? For databases, models, configurations, and anything that needs to persist.

When should I use bind mounts? When you need to read from or write to the host directory directly.

Where are named volumes stored? On Linux, typically in /var/lib/docker/volumes/.

How do I back up volumes? Use tar via a temporary container or docker cp.

Are volumes faster than bind mounts? In most cases, the difference is negligible. Bind mounts can be slower on network filesystems.

Sources and Further Reading

• Docker Volumes: https://docs.docker.com/storage/volumes/
• Docker Bind Mounts: https://docs.docker.com/storage/bind-mounts/
• Docker Storage: https://docs.docker.com/storage/

Summary: Managing Docker Volumes

Docker volumes are key to persistent data in containers. Named volumes are convenient and portable, while bind mounts offer direct host access. With proper planning, regular backups, and attention to permissions, you avoid data loss and keep your AI services stable. For Ollama, databases, and web interfaces especially, volumes are essential so that models and configurations remain available after a restart.