Как переместить Docker-данные на другой раздел

Почему важно переместить Docker-томы на отдельный раздел

Docker по умолчанию хранит свои данные в /var/lib/docker, который обычно находится на корневом разделе (/). По мере работы контейнеров туда накапливается много постоянных данных: образы, контейнерные слои, логи и тома. Если корневой раздел заполнится, система может начать тормозить, контейнеры перестанут сохранять данные, возможны неожиданные сбои.

Переезд томов или всего каталога Docker на отдельный диск помогает:

• освободить место на корневом разделе;
• снизить риск сбоев из‑за переполнения диска;
• хранить большие данные (базы, логи) на выделенном хранилище;
• упростить управление бэкапами и производительностью диска.

Образец: СУБД в контейнерах (MySQL, PostgreSQL) часто генерируют гигабайты данных. Вынос тома на отдельный раздел улучшает устойчивость системы.

Что должно быть готово перед началом

• У вас есть доступ root или sudo на хосте.
• Вы можете остановить контейнеры и сервис Docker (в рабочее время или плановое окно обслуживания).
• На целевом разделе достаточно места и он смонтирован, например, в /mnt/docker-data или /data.
• Вы понимаете, какой том или каталоги нужно переместить.

Важно: делайте резервную копию перед критическими операциями и тестируйте на тестовом сервере, если это возможно.

Как найти Docker-томы и каталоги данных

Список всех томов Docker:

docker volume ls

Информация по конкретному тому:

docker volume inspect volume_name

В выводе найдите поле Mountpoint — это реальная папка в файловой системе, где Docker хранит данные тома.

Вариант A — переместить весь Docker root (/var/lib/docker)

Когда имеет смысл: если заполнен весь /var/lib/docker или вы хотите перенести и тома, и образы, и контейнеры одновременно.

Основная методика (минимальная, но безопасная): остановить Docker, rsync копирование, изменить data-root, перезапустить, проверить.

Шаги:

1. Остановите Docker:

sudo systemctl stop docker

2. Скопируйте данные на новый раздел. Базовый вариант:

sudo rsync -avxP /var/lib/docker/ /path/to/new/partition/docker-data/

Рекомендуемый вариант (с сохранением hard links, ACL и расширенных атрибутов):

sudo rsync -aHAX --info=progress2 /var/lib/docker/ /mnt/docker-data/

3. Переименуйте старую папку как резервную копию:

sudo mv /var/lib/docker /var/lib/docker.old

4. Обновите конфигурацию Docker — создайте или отредактируйте файл /etc/docker/daemon.json:

sudo nano /etc/docker/daemon.json

Добавьте (или измените) параметр data-root:

{  
"data-root": "/path/to/new/partition/docker-data"  
}

5. Перезапустите Docker и проверьте новый путь:

sudo systemctl start docker

docker info | grep "Docker Root Dir"

(если в выводе указан новый путь, миграция прошла успешно). Если всё в порядке — удалите резервную копию:

sudo rm -rf /var/lib/docker.old

Важно: если на системе включён SELinux, проверьте контексты безопасности на новом разделе (restorecon или chcon). Также убедитесь, что файловая система поддерживает необходимые атрибуты (xattrs).

Когда этот подход не подходит: если вы не можете остановить Docker долгое время или у вас критичные контейнеры без возможности миграции в окно обслуживания.

Вариант B — переместить только конкретный том и использовать bind mount

Когда имеет смысл: нужно освободить место, но трогать все данные Docker нецелесообразно — например, база данных в одном томе.

Шаги:

1. Остановите контейнер, который использует том:

docker stop container_name

2. Скопируйте данные из тома на новый каталог на хосте:

sudo rsync -a /var/lib/docker/volumes/my_volume/_data/ /data/docker/my_volume/

3. Измените docker-compose.yml (или команду docker run), чтобы использовать bind mount вместо именованного тома:

services:
  my_service:
    volumes:
      - /data/docker/my_volume:/container/path

4. Перезапустите контейнеры:

docker-compose up -d

Проверки: убедитесь, что внутри контейнера данные доступны и права/владельцы корректны. При необходимости исправьте права на хосте (chown/chmod).

Примечание: при использовании bind mount вы напрямую управляете путём на хосте, что упрощает бэкапы и мониторинг.

Метод GUI — Docker Desktop (Windows / macOS)

Docker Desktop поддерживает изменение местоположения хранения образа (Disk Image Location). Это переносит весь набор данных Docker (образы, контейнеры, тома и кеш сборки).

1. Откройте Docker Desktop → Settings → Resources → Advanced.
2. В поле Disk Image Location нажмите Browse и выберите папку на новом разделе (например, /mnt/newdisk/docker-data).
3. Нажмите Apply & Restart — Docker Desktop перезапустит и переместит данные.

Ограничение GUI: нет возможности перемещать отдельные тома через интерфейс — только весь образ диска.

Проверки и критерии приёмки

Критерии приёмки после миграции:

• docker info показывает новый Docker Root Dir.
• Контейнеры запускаются без ошибок.
• Данные в контейнерах (например, БД) целы и соответствуют контрольным суммам/записям.
• Нет ошибок доступа (permission denied) в логах Docker или приложений.
• Старый каталог либо удалён, либо сохранён как резервная копия.

Пример тестов:

• Запуск контейнера с тестовым файлом: создать файл в контейнере, убедиться, что он появился на новом разделе.
• Для БД: выполнить дамп таблицы до и после миграции и сравнить.

Контрпримеры и риски — когда миграция может не сработать

• Целевой том смонтирован с параметрами, запрещающими сохранение xattr или hard links — это может нарушить целостность Docker-данных.
• На целевой файловой системе недостаточно прав или SELinux мешает доступу. Решение: настроить контексты SELinux и права.
• При прерывании rsync (например, из‑за сбоя питания) копирование может быть неполным — используйте –partial и проверяйте контрольные суммы.
• Если вы меняете только data-root, но не переносите данные, Docker создаст новую пустую директорию, что приведёт к потере текущих образов/томов — убедитесь, что данные скопированы до смены конфигурации.

Советы и эвристики (mental models)

• Heuristic 1: Если >30–50% используемой ёмкости /var/lib/docker — рассмотрите перенос.
• Heuristic 2: Разделяйте данные по характеру: логи и кеши — на быстрые SSD; архивные бэкапы — на медленные NAS.
• Heuristic 3: Используйте bind mount для критичных данных, которые должны быть доступными для бэкапа хоста.

Роли и чеклисты

Системный администратор:

• Проверить наличие свободного места на целевом разделе.
• Настроить монтирование с правильными флагами и правами.
• Проверить SELinux/AppArmor контексты.

DevOps-инженер:

• Запланировать окно обслуживания.
• Обновить daemon.json и протестировать на dev-среде.
• Настроить мониторинг использования диска.

Разработчик/владелец приложения:

• Проверить, что приложение корректно пишет в том.
• Выполнить функциональные тесты после миграции.

Мини‑методология: план миграции (шаблон)

1. Оценка: определить, какие данные занимают место.
2. Подготовка: подготовить целевой раздел, права и контексты.
3. Остановка: остановить Docker/контейнеры в окне обслуживания.
4. Копирование: rsync с подходящими флагами.
5. Конфигурация: обновить daemon.json или docker-compose.
6. Проверка: запустить контейнеры, прогнать тесты целостности.
7. Уборка: удалить старую папку после проверки.

Безопасность и соответствие (коротко)

• При переносе данных, содержащих персональные данные, соблюдайте правила хранения и шифрования. Перенос на внешний диск должен быть зашифрован, если этого требуют регламенты.
• Ограничьте доступ к каталогу с Docker-данными только нужным системным учеткам.

Совместимость и лайфхаки

• Системd и daemon.json: параметр data-root поддерживается в современном Docker. На устаревших сборках названия опций могли отличаться.
• Для XFS с ftype=0 возможны проблемы с overlay2; проверьте тип файловой системы и её свойства.
• Если целевой диск — сетевой (NFS), учитывайте производительность и семантику атрибутов файловой системы.

Decision flow (когда выбрать какой метод)

flowchart TD
  A[Заполнен /var/lib/docker?] -->|Нет| B[Мониторить и очищать]
  A -->|Да| C[Есть окно обслуживания?]
  C -->|Да| D[Перенос всего /var/lib/docker]
  C -->|Нет| E[Перенос отдельных томов через bind mounts]
  D --> F[Остановить Docker -> rsync -> update daemon.json -> старт]
  E --> G[Остановить контейнеры -> rsync тома -> изменить compose -> рестарт]

Заключение

Перенос Docker-томов или всего каталога данных на отдельный раздел — простая и надёжная мера для управления дисковым пространством и повышения отказоустойчивости. Выбор между полным переносом и миграцией отдельных томов зависит от ваших требований к простоту, времени простоя и административного контроля.

Важно выполнить шаги последовательно: остановка сервиса, корректное копирование с сохранением атрибутов, обновление конфигурации и тестирование. Не забывайте о правах, SELinux и возможных особенностях целевой файловой системы.

Краткий план действий:

• Оцените проблему → выберите стратегию → выполните копирование с rsync → обновите конфигурацию → проверьте → удалите старые данные.

Итог: правильная миграция освобождает корневой раздел, уменьшает риск аварий и упрощает бэкап и масштабирование хранилища.

Summary

• Перемещайте весь Docker, если нужен «чистый» перенос всех артефактов.
• Переносите отдельные тома через bind mounts, если хотите минимизировать риск и время простоя.
• Используйте rsync -aHAX для сохранения атрибутов и прогресса.
• Проверяйте права, SELinux и тестируйте целостность данных.