Резервное копирование Docker томов

Резервное копирование Docker томов нужно автоматизировать: создайте временный контейнер, подключите нужный том и выгрузите его содержимое в архив (tar/gzip). Храните архивы вне хоста, тестируйте восстановление и учитывайте особенности драйверов томов и безопасности.

Быстрые ссылки

• Управление резервными копиями томов
• Восстановление из резервной копии
• Резервное копирование напрямую с хоста
• Практические методики, чек-листы и SOP
• Итог

Docker тома используются для хранения постоянных данных отдельно от контейнеров. Данные в томе остаются доступными после остановки контейнера, что позволяет контейнеризовать stateful-приложения. Тем не менее, одном факте того, что томы живут дольше контейнеров, часто недостаточно — нужен надежный план резервного копирования и восстановления.

Управление резервными копиями томов

Docker не предоставляет встроенного механизма для создания резервных копий содержимого томов. Вам нужно организовать доступ к тому и скопировать его данные в пункт хранения резервных копий.

Часто самый простой и переносимый подход — создать временный контейнер, смонтировать в него нужный том и упаковать содержимое в архив. Для этого используются флаги –volumes-from, -v и утилиты tar/gzip.

Пояснение терминов в одну строку:

• ТОМ — логическое хранилище данных Docker, отделённое от жизни контейнера.
• ВРЕМЕННЫЙ КОНТЕЙНЕР — контейнер, создаваемый только для операции бэкапа или восстановления и удаляемый после неё.

Ниже — рабочий пример, шаг за шагом.

1. Создаём контейнер, который использует том mysql_data (пример создания приложения):

# Создать контейнер с томом mysql_data
docker run -d \
  --name mysql \
  -v mysql_data:/var/lib/mysql \
  -e MYSQL_ROOT_PASSWORD=mysql \
  mysql:8

2. Создаём временный контейнер, который получает доступ к томам контейнера mysql и выгружает архив в текущую рабочую директорию хоста:

# Создать архив тома mysql_data в каталоге на хосте
docker run --rm \
  --volumes-from mysql \
  -v "$PWD":/backup-dir \
  ubuntu tar cvf /backup-dir/mysql-backup.tar /var/lib/mysql

Разбор ключевых опций:

• –volumes-from mysql — временный контейнер получает те же тома, что и контейнер mysql.
• -v “$PWD”:/backup-dir — биндим каталог хоста (текущая директория) в контейнер, чтобы сохранить архив на хост.
• /var/lib/mysql — путь внутри контейнера mysql, где хранятся данные MySQL. Именно его архивируют.
• –rm — автоматически удаляет временный контейнер после завершения команды.

Архив окажется в каталоге на хосте и готов к перемещению в долгосрочное хранилище. Команду создания архива удобно запускать по cron или через планировщик систем оркестрации.

Важно: используйте gzip (tar czvf) для сжатия, если нужно уменьшить размер файлов, и проверяйте целостность архива после создания (tar tvf /path/to/archive).

Восстановление из резервной копии

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

Пример восстановления в тот же том:

# Восстановление в том, подключённый к контейнеру mysql
docker run --rm \
  --volumes-from mysql \
  -v "$PWD":/backup-dir \
  bash -c "cd /var/lib/mysql && tar xvf /backup-dir/mysql-backup.tar"

Риски и рекомендации:

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

docker stop mysql
# выполнить восстановление
docker start mysql

• Если восстанавливаете на новый хост, создайте пустой том заранее:

docker volume create new_volume

И смонтируйте его для распаковки:

docker run --rm \
  -v new_volume:/var/lib/mysql \
  -v "$PWD":/backup-dir \
  ubuntu bash -c "cd /var/lib/mysql && tar xvf /backup-dir/mysql-backup.tar"

После этого старт контейнера с тем же томом обеспечит доступ к восстановленным файлам.

Совет по тестированию: периодически разворачивайте резервные копии на отдельном стенде и проверяйте работоспособность приложения и целостность данных.

Резервное копирование томов напрямую с хоста

Иногда удобно архивировать данные напрямую в файловой системе хоста. По умолчанию содержимое томов можно найти в каталоге:

/var/lib/docker/volumes

Структура обычно такая:

• /var/lib/docker/volumes//_data — именно здесь лежат файлы тома.

Архивирование всего каталога можно выполнить так:

sudo tar czvf /backup-dir/docker-volumes-$(date +%F).tar.gz /var/lib/docker/volumes

Ограничения и предостережения:

• Права root: большинство файлов там принадлежат root, поэтому нужен sudo.
• Непереносимость: если вы используете нестандартный драйвер томов (network plugin, cloud volume, NFS), данные могут физически находиться вне /var/lib/docker/volumes. Полная архивация этого каталога не гарантирует копирование всех томов.
• Риск «точки в записи»: если контейнеры активно пишут в том при создании архива, он может получиться неконсистентным. Лучше останавливать сервисы или использовать файловые снимки (LVM, драйвер томов с snapshot) для получения консистентной копии.

Когда этот подход не работает — примеры

• Том использует облачный/сетевой драйвер (например, AWS EBS, Azure Disk, NFS): данные могут не храниться в /var/lib/docker/volumes. В таком случае используйте механизмы снапшотов провайдера.
• Базы данных с высокими требованиями к консистентности: простой tar может не гарантировать корректных данных. Используйте встроенные средства бэкапа приложения (например, mysqldump, pg_basebackup) или остановите сервис перед снимком.
• Большие объёмы данных: хранение большого архива на локальном диске может быть непрактичным. Подумайте о стриминге архива в сетевое хранилище или облако (tar | gzip | curl/gsutil).

Альтернативные подходы

• Приложенческие бэкапы: использовать экспорт/дамп приложения (mysqldump, pg_dump). Это даёт приложению-консистентный бэкап.
• Резервные решения уровня хоста: LVM/ZFS снапшоты или файловые системы с копированием при записи.
• Инструменты резервного копирования: restic, Duplicity, Borg — умеют шифровать, дедуплицировать и отправлять данные в облако.
• Плагины Docker Volume Drivers: некоторые драйверы поддерживают собственные механизмы бэкапа/снапшотов.

Методика быстрого тестирования бэкапов (мини-методология)

1. Создайте контрольные данные в объёме (несколько файлов, запись базы).
2. Сделайте резервную копию по стандартному сценарию.
3. Восстановите архив в отдельный том на тестовом хосте.
4. Запустите сервис с восстановленным томом и выполните проверку целостности и работоспособности.
5. Документируйте результаты и исправьте сценарий при обнаружении проблем.

Чек-листы по ролям

Чек-лист для DevOps / SRE:

• Автоматизировать создание архивов (cron, systemd timer, CI).
• Отправлять архивы в удалённое хранилище (S3, GCS, NFS).
• Следить за доступностью места и ротацией архивов.
• Проводить регулярные тесты восстановления.

Чек-лист для DBA:

• Оценивать, хватает ли tar-архива для обеспечения консистентности СУБД.
• Настроить приложения или инструменты СУБД для корректных бэкапов (инкрементные, дампы).
• Планировать окна обслуживания для полного snapshot-бэкапа.

Чек-лист для инженера безопасности:

• Шифровать резервные копии в покое и при передаче.
• Минимизировать число людей с доступом к архивам.
• Устанавливать политики хранения и удаления (retention).

SOP: стандартная процедура резервного копирования тома

1. Подготовка каталога на хосте для временного хранения архива: mkdir -p /backups/docker
2. Запустить команду бэкапа с временным контейнером:

docker run --rm \
  --volumes-from  \
  -v /backups/docker:/backup-dir \
  ubuntu bash -c "tar czvf /backup-dir/-$(date +%F).tar.gz /path/to/volume"

3. Переместить или загрузить архив в удалённое хранилище (scp/rsync/s3/gcloud).
4. Проверить целостность архива: tar tzf /path/to/archive.tar.gz > /dev/null && echo OK
5. Очистить локальные временные архивы по политикам хранения.

Критерии приёмки

• Архив успешно создаётся и содержит ожидаемые файлы.
• Архив можно распаковать без ошибок на тестовом окружении.
• Восстановленный сервис проходит базовую проверку работоспособности.
• Архивы зашифрованы и доступны в удалённом хранилище.

Тестовые сценарии

• Создать изменённую базу и выполнить бэкап, затем восстановить и проверить данные.
• Попробовать восстановление в новый том и запустить сервис.
• Проверить поведение при случае, если том использует сетевой драйвер (имитировать недоступность хранилища).

Безопасность, соответствие и GDPR

• Шифруйте резервные копии (на стороне клиента) перед отправкой в облако.
• Храните минимально необходимую персональную информацию в архивах, если это возможно.
• Убедитесь, что политика хранения данных соответствует требованиям регуляторов (удаление по требованию, сроки хранения).

Шпаргалка команд (cheat sheet)

• Создать том: docker volume create
• Создать контейнер с томом: docker run -d –name app -v :/data image
• Сделать архив тома: docker run –rm –volumes-from app -v “$PWD”:/backup ubuntu tar cvf /backup/app.tar /data
• Восстановление: docker run –rm –volumes-from app -v “$PWD”:/backup ubuntu bash -c “cd /data && tar xvf /backup/app.tar”
• Архив сжатый: tar czvf archive.tar.gz /data

Итог

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

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

Факт-бокс — ключевые места и команды:

• Каталог томов по умолчанию: /var/lib/docker/volumes
• Путь внутри тома: _data
• Основные команды: docker run, docker volume create, docker stop/start
• Утилиты: tar, gzip, rsync, scp, restic

Примечание: перед массовым применением на продакшне протестируйте процедуру восстановления и адаптируйте её под специфику приложений (СУБД, файловые системы, сетевые драйверы томов).