Docker Volumes vs Bind Mounts: Managing Data Persistence

Losing all your Nextcloud files or Jellyfin media library the moment a container gets recreated is a frustrating lesson many homelab users learn the hard way. Understanding Docker volumes vs bind mounts is essential for making sure your actual data survives container updates, restarts, and rebuilds — since containers themselves are meant to be disposable, but your data absolutely shouldn’t be.

Why Containers Need Persistent Storage

By default, any data written inside a running container disappears the moment that container is removed, since containers are designed to be ephemeral, disposable units. For stateless applications this is fine, but for anything storing real data — a database, uploaded files, configuration — you need a way to keep that data outside the container’s own disposable filesystem.

What Are Bind Mounts?

A bind mount maps a specific directory on the host machine directly into the container, making that host path directly accessible from inside the container at whatever mount point you specify:

yaml

services:
  jellyfin:
    image: jellyfin/jellyfin
    volumes:
      - /mnt/storage/media:/media
      - /mnt/storage/jellyfin-config:/config

Here, /mnt/storage/media on the host becomes accessible as /media inside the container, and changes made from either side are immediately visible to the other.

What Are Docker Volumes?

Docker volumes are managed entirely by Docker itself, stored in a location Docker controls (typically under /var/lib/docker/volumes/) rather than a path you choose directly:

yaml

services:
  nextcloud:
    image: nextcloud
    volumes:
      - nextcloud-data:/var/www/html

volumes:
  nextcloud-data:

Docker manages the underlying storage location, providing a layer of abstraction between your host filesystem and the container’s data.

Key Differences

• Location control – bind mounts let you choose exactly where on your host filesystem the data lives; volumes hide this behind Docker’s own management
• Portability – volumes work identically regardless of the specific host filesystem layout, making Compose files more portable across different machines; bind mounts require the specified host path to actually exist with the same structure
• Backup convenience – bind mounts are easy to back up directly, since you know exactly which host directory to include in your backup routine; volumes require either using docker volume commands or knowing Docker’s internal storage path
• Permissions handling – bind mounts inherit the host filesystem’s existing permissions and ownership, occasionally causing permission mismatches between the host user and the container’s internal user; volumes are managed entirely by Docker, sidestepping some of these issues

When to Use Bind Mounts

Bind mounts work well when you want direct, easy access to the underlying files from the host — for example, media files you also want to browse or manage directly from the host system, or configuration files you want to edit with a regular text editor without needing Docker-specific commands.

When to Use Docker Volumes

Volumes are generally preferred for application data that doesn’t need direct host-level access — database storage, application state, or anything where you’re comfortable letting Docker manage the underlying location, especially in setups aiming for maximum portability across different host machines.

Backing Up Bind Mounts

Since bind mount data lives at a known host path, back it up using standard tools directly — rsync, tar, or as part of a broader VM-level backup if the container runs inside a Proxmox VM:

tar -czf jellyfin-config-backup.tar.gz /mnt/storage/jellyfin-config

Backing Up Docker Volumes

For named volumes, use Docker’s own volume commands to locate and back up the data:

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

This temporarily mounts the volume into a throwaway Alpine container just long enough to create a compressed archive of its contents.

A Practical Approach for Homelab Use

Many homelab users default to bind mounts for nearly everything, specifically because of the backup and direct-access convenience they provide, reserving named volumes mainly for cases where a specific application’s documentation recommends them or where portability across different host setups genuinely matters.

Final Thoughts

Understanding Docker volumes vs bind mounts ensures your actual data survives container recreations, image updates, and rebuilds without unpleasant surprises. For most homelab setups prioritizing straightforward backups and direct host access, bind mounts remain the simpler, more transparent default — with named volumes reserved for the specific cases where Docker’s own storage management genuinely adds value.