Де зберігаються Docker volumes на хост-системі?

docs.questions.sections.docker~3 хв читання

Docker volume живуть десь на диску, але «десь» залежить від OS, від того, volume у тебе чи bind mount, і від конфігурації сховища Docker. Знання відповіді допомагає з бекапами, дебагом permission і disaster recovery.

Теорія

TL;DR

Linux: /var/lib/docker/volumes/<volume-name>/_data/ (root-owned, читається з sudo).
macOS / Windows: той самий шлях, але всередині Linux VM Docker Desktop. Не видно прямо з Finder / Explorer.
Знайти шлях конкретного volume: docker volume inspect <name> --format '{{.Mountpoint}}'.
Розташування налаштовується через daemon-опцію data-root.
Ніколи не редагуй файли напряму, поки container їх відкритий, дай Docker посередничати.

Швидкий приклад

bash

# Створимо volume і запишемо в нього через container
$ docker volume create demo
$ docker run --rm -v demo:/data alpine sh -c 'echo hello > /data/note.txt'

# Де лежить файл?
$ docker volume inspect demo --format '{{.Mountpoint}}'
/var/lib/docker/volumes/demo/_data

# На Linux sudo показує
$ sudo cat /var/lib/docker/volumes/demo/_data/note.txt
hello

# На macOS / Windows: цей шлях у VM. З host його не бачиш.
# Читай через container натомість:
$ docker run --rm -v demo:/data alpine cat /data/note.txt
hello

Поле Mountpoint каже правду на кожній платформі. Видимість у shell різна.

Чому Mac / Windows ховають шлях volume

Docker Desktop на macOS і Windows крутить увесь Docker engine всередині Linux VM (бо container'ам потрібен Linux kernel). Volume лежать на filesystem VM, не host. Filesystem host бачить переважно лише image-файл VM (Docker.raw на Mac, ext4.vhdx на WSL).

Результат: ls /var/lib/docker/volumes/... не працює на host Mac/Windows. Маєш або:

Читати дані через тимчасовий container (docker run --rm -v vol:/data alpine cat /data/...)
Або брати bind mount замість volume, коли важливе host-side редагування (Compose dev-workflow це і робить)

Анатомія `/var/lib/docker/volumes/`

/var/lib/docker/volumes/
├── metadata.db                  # bolt DB метаданих volume
├── pgdata/
│   └── _data/                   # реальний вміст volume
│       ├── PG_VERSION
│       ├── base/
│       └── ...
├── webdata/
│   └── _data/
│       └── index.html
└── 7f8a3e2d.../                  # анонімний volume (UUID-ім'я)
    └── _data/

Кожен volume = одна директорія. Всередині _data/ це реальний mount-корінь. Wrapper-директорія тримає метадані Docker.

Зміна розташування сховища

Якщо /var/lib/docker на неправильному диску, спрямуй daemon в інше місце через /etc/docker/daemon.json:

json

{
  "data-root": "/mnt/big-disk/docker"
}

Рестартуй dockerd (systemctl restart docker), і daemon тепер зберігає все (image, container, volume) під новим шляхом. Міграція існуючих даних окрема операція: зупини docker, скопіюй /var/lib/docker у новий шлях, стартуй docker.

Типові помилки

Редагування файлів volume на Linux, поки container running

bash

$ sudo vi /var/lib/docker/volumes/pgdata/_data/postgresql.conf
# Postgres ці файли тримає відкритими. Твоє редагування може корумпувати on-disk стан.

Завжди спочатку зупини container, редагуй, рестарт. Краще: використай docker exec і редагуй через container, або змонтуй config-файл як окремий read-only bind mount і не чіпай volume.

Спроба знайти volume на macOS

bash

$ ls /var/lib/docker/volumes
ls: /var/lib/docker/volumes: No such file or directory

VM має; host ні. Бери docker run --rm -v <name>:/data alpine ls /data, щоб прочитати вміст з container.

Видалення /var/lib/docker/volumes/<name> напряму

bash

$ sudo rm -rf /var/lib/docker/volumes/myvol

Оминає метадані Docker. Volume може ще з'являтися у docker volume ls, але бути зламаним. Бери docker volume rm myvol.

Бекап volume копіюванням host-шляху під час use

Volume може мати файли мід-write. Краще: dump через container.

bash

# Live backup через container, консистентний, якщо застосунок quiescent
docker run --rm -v pgdata:/data -v $PWD:/backup alpine \
  tar czf /backup/pgdata.tar.gz -C /data .

Для баз спеціально, бери native dump БД (pg_dump), file-level копія живої БД ризикує корупцією.

Реальне застосування

Бекапи: docker run --rm -v <vol>:/data -v $PWD:/backup alpine tar czf /backup/<vol>.tar.gz -C /data . cross-platform патерн.
Міграція на більший диск: зупини docker, скопіюй /var/lib/docker на новий диск, постав data-root у daemon.json, рестарт.
Troubleshooting permission: docker volume inspect для Mountpoint, sudo ls -la <Mountpoint> для перевірки ownership (Linux), потім фікс через chown з container з відповідним --user.
Disk-full alert на Linux: du -sh /var/lib/docker/volumes/*/_data | sort -h показує, який volume слон.

Питання для поглиблення

Q: Яка різниця між розташуванням volume і bind-mount?

A: Volume у Docker-managed шляхах під data-root. Bind mount використовує будь-який host-шлях, що ти задаєш у -v. Volume відповідальність Docker; bind mount твоя.

Q: Чи можу шарити той самий /var/lib/docker між двома Docker-інсталами?

A: Ні, ніколи. Два daemon, що пишуть у той самий data-root, корумпують один одного. Кожна Docker-інсталяція потребує свій data-root.

Q: Де volume на Docker Desktop для Mac конкретно?

A: Всередині ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw (image-диск VM). Шлях всередині VM той самий /var/lib/docker/volumes/.... Щоб зазирнути, використай docker desktop terminal або docker run --rm -v <vol>:/data alpine ls /data.

Q: Як називаються анонімні volume?

A: SHA-like hash, наприклад 7f8a3e2d6c5a.... З'являються, коли директива VOLUME image відпрацьовує без -v <name>:. Знайди через docker volume ls -f dangling=true.

Q: (Senior) Як мігрувати volume з одного host на інший?

A: Портативний підхід: docker run --rm -v old-volume:/data -v $PWD:/out alpine tar czf /out/data.tar.gz -C /data . на старому host. Перенеси tarball. На новому: docker volume create new-volume && docker run --rm -v new-volume:/data -v $PWD:/in alpine tar xzf /in/data.tar.gz -C /data. Пряме копіювання /var/lib/docker/volumes/<name>/ між host теж працює, якщо обидва Linux з тією ж Docker-версією, але tar+restore це те, що пишеш у runbook.

Приклади

Inspecting volume

bash

$ docker volume inspect pgdata
[
    {
        "CreatedAt": "2026-04-15T10:30:00Z",
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "/var/lib/docker/volumes/pgdata/_data",
        "Name": "pgdata",
        "Options": null,
        "Scope": "local"
    }
]

Mountpoint це відповідь. Driver local означає «директорія під data-root». Інші драйвери (NFS, AWS EFS) вказують деінде.

Читання вмісту volume з будь-якої OS

bash

$ docker run --rm -v pgdata:/data alpine ls -la /data
total 156
drwx------    19 70       70             4096 ...
-rw-------     1 70       70                3 ... PG_VERSION
drwx------     5 70       70             4096 ... base
-rw-------     1 70       70             4760 ... pg_hba.conf
...

Запускає крихітний container, монтує volume, виконує ls. Працює ідентично на Linux, Mac, Windows. Cross-platform відповідь на «що у цьому volume?».

Backup і restore loop

bash

# Backup
$ docker run --rm \
    -v pgdata:/data \
    -v $PWD:/backup \
    alpine \
    tar czf /backup/pgdata-$(date +%F).tar.gz -C /data .

# Restore (у свіжий порожній volume)
$ docker volume create pgdata-restored
$ docker run --rm \
    -v pgdata-restored:/data \
    -v $PWD:/backup \
    alpine \
    tar xzf /backup/pgdata-2026-04-30.tar.gz -C /data

Чистий, OS-незалежний backup-патерн. Для баз бери pg_dump / mysqldump для application-level консистентності, але tar-патерн нормальний для статичних volume (config, аплоади).

Коротка відповідь

Для співбесіди

Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.

Коментарі

Ще немає коментарів