备份Docker卷：直接tar归档/var/lib/docker/volumes目录是否可行？

Great question—let’s break this down clearly, since this is a common point of confusion when working with Docker volumes.

Why Docker Recommends the Temporary Container Backup Method #

The official approach using a throwaway container with --volumes-from isn’t just arbitrary—it solves several key problems you might run into with direct filesystem backups:

• No dependency on Docker’s internal structure: Docker’s volume directory layout (like the /_data subfolder inside each volume’s directory) isn’t part of its public API. It could change between Docker versions or storage drivers (e.g., overlay2 vs. zfs). Using --volumes-from lets you access the volume exactly as the application container sees it, avoiding any reliance on hidden internal paths.
• Proper permission handling: Containerized apps often run with non-root UIDs/GIDs (e.g., PostgreSQL uses UID 999, Redis uses 999 too in some images). When you back up via a container, you’re working within the same user namespace context as the app. This ensures file ownership and permissions are preserved in a way that’s compatible with how the container expects them. Directly backing up from the host might retain the numeric UIDs, but those IDs could map to different users on another host, leading to permission denied errors when restoring.
• Flexibility for consistent backups: If you need to run app-specific tools to ensure data consistency (like pg_dump for PostgreSQL or redis-cli SAVE), you can use a temporary container based on the same app image (or one with the necessary tools installed). This lets you trigger consistent dumps directly from the container context, rather than trying to copy potentially half-written files from the host filesystem.

Risks of Directly Archiving /var/lib/docker/volumes/VOLUME #

While technically possible, directly tarring the volume directory has several gotchas:

• You’re backing up Docker metadata, not just your data: Each volume directory contains more than just your app’s data (the /_data folder). There are internal files like config.json, _refs, and storage driver-specific artifacts. Including these in your backup can cause conflicts when restoring—Docker might not recognize the volume if you overwrite these metadata files on a new host, or the metadata might not match the new host’s Docker setup.
• Permission mismatches across hosts: As mentioned earlier, numeric UIDs/GIDs don’t always translate between hosts. A UID 999 on your current host might be a random system user on the target host, leading to the container being unable to read its own data after restore.
• Locked files and incomplete backups: If the container is running, some files might be held open by the app process. Tarring from the host can result in incomplete or corrupted files (e.g., a database write in progress). While this risk exists with the container method too, the container approach makes it easier to run pre-backup commands (like quiescing the database) to mitigate this.

On Data Consistency #

You’re absolutely right—both methods carry a risk of inconsistent backups if the app is actively writing data during the backup. The fix here isn’t tied to the backup method itself, but rather how you prepare the data:

• For low-impact scenarios, temporarily stop the container before backing up.
• For production systems, use app-specific tools (like database dumps) to create a consistent snapshot, which is far easier to do via a temporary container than trying to run those tools on the host.

内容的提问来源于stack exchange，提问作者gypark