Hey there! Let’s unpack your questions about non-external volumes and whether they’re a solid choice for persisting PostgreSQL data when running a Linux-based Docker image on Windows.

What Exactly is a Non-External Volume? #

Non-external volumes are Docker-managed storage volumes that live entirely within Docker’s own filesystem (on Windows, this is typically inside the WSL2 backend since you’re using a Linux image). Unlike bind mounts (where you map a specific Windows folder to the container), you don’t specify a host path—Docker handles where the data is stored behind the scenes.

For example, to create one via the command line:

docker volume create postgres_data

Or in a docker-compose.yml file:

services:
  postgres:
    image: postgres:latest
    environment:
      POSTGRES_USER: your_user
      POSTGRES_PASSWORD: your_password
    volumes:
      - postgres_data:/var/lib/postgresql/data
volumes:
  postgres_data:
    # No external: true here means it's a non-external volume

Why Did Mounting a Windows Host Directory Cause Issues? #

The root problem is filesystem and permission incompatibility between Windows (NTFS) and Linux. The PostgreSQL process in your Linux container runs as the postgres user (usually UID 999), which doesn’t have proper permissions to read/write to a Windows-hosted directory. Additionally, Linux-specific filesystem features (like file permissions, symbolic links, and ownership) don’t translate cleanly to NTFS, leading to startup failures or potential data corruption.

Are Non-External Volumes a Good Persistence Solution for Dockerized PostgreSQL? #

Absolutely—this is actually one of the recommended approaches for your setup. Here’s why:

• Permission Compatibility: Since the volume lives in the WSL2 filesystem (matching your Linux container’s environment), you won’t run into permission errors that plague bind mounts to Windows folders.
• Data Reliability: Docker manages these volumes securely—your data stays intact even if the Docker daemon crashes, the container is deleted, or you restart your machine. Volumes aren’t tied to the lifecycle of a container, so you can spin up a new PostgreSQL container and reattach the same volume to pick up right where you left off.
• Better Performance: WSL2’s native filesystem is significantly faster for Linux containers than cross-system bind mounts to Windows. This is critical for PostgreSQL, which is IO-intensive.
• Ease of Management: You can list, inspect, or delete volumes using simple Docker commands (docker volume ls, docker volume inspect postgres_data, etc.), no need to track down specific host folders or fix permission issues manually.

Quick Tips for Working with Non-External Volumes #

• Backups: You have two solid options here:
  1. Volume-level backup: Use a temporary container to archive the volume’s contents:

     docker run --rm -v postgres_data:/data -v $(pwd):/backup ubuntu tar cvzf /backup/postgres_backup.tar.gz /data
     

  2. Logical backup: Use PostgreSQL’s built-in pg_dump for a more portable backup:

     docker exec -it your_postgres_container_name pg_dump -U your_db_user your_db_name > backup.sql
     

• Volume Cleanup: Remember that deleting a container doesn’t delete its attached volumes. To remove a volume (and its data), run docker volume rm postgres_data—only do this if you’re sure you don’t need the data anymore.

内容的提问来源于stack exchange，提问作者Cheok Yan Cheng