Надежное резервное копирование и восстановление Docker Volumes: полное практическое руководство | AdminWiki
Logo

Надежное резервное копирование и восстановление Docker Volumes: полное практическое руководство

02 апреля 2026 7 мин. чтения
Содержание статьи

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

В этой инструкции показано резервное копирование Docker Volumes с помощью docker-volume-backup, загрузка в S3-совместимые хранилища Yandex Cloud Object Storage и MinIO, а также восстановление данных на тот же или новый хост. Отдельно отмечены ограничения консистентности и порядок проверки результата.

Быстрый старт: резервное копирование Docker Volumes

  1. Установите Docker и Docker Compose, подготовьте Docker Volume и S3-совместимое хранилище.
  2. Создайте docker-compose.yml, укажите имя тома, расписание, endpoint, бакет и ключи доступа.
  3. Сохраните AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY в файле .env, который не должен попадать в системы контроля версий.
  4. Запустите службу командой docker-compose up -d, затем выполните ручную проверку: docker exec volume_backup backup.
  5. Проверьте наличие архива в бакете и периодически выполняйте тестовое восстановление.

Для бэкапа Docker volume без остановки контейнера используется docker-volume-backup. Однако консистентность зависит от приложения и его файловой системы: для PostgreSQL, MySQL, Redis и других stateful-приложений нужно использовать штатный механизм дампа или обеспечить согласованную остановку записи.

Пошаговая настройка автоматического бэкапа с docker-volume-backup и cron

Для большинства рабочих сред оптимальным балансом простоты настройки и возможностей является специализированный инструмент docker-volume-backup, упакованный в Docker-образ.

Готовый docker-compose.yml:

version: '3.8'

services:
  backup:
    image: offen/docker-volume-backup:latest
    container_name: volume_backup
    restart: unless-stopped
    environment:
      # Имя источника данных внутри контейнера бэкапа
      BACKUP_SOURCES: /backup_sources
      # Расписание: каждый день в 2:00
      BACKUP_CRON_EXPRESSION: "0 2 * * *"
      # S3-compatible storage, пример для Yandex Cloud
      AWS_ENDPOINT: "https://storage.yandexcloud.net"
      AWS_S3_BUCKET_NAME: "your-backup-bucket"
      AWS_ACCESS_KEY_ID: "${AWS_ACCESS_KEY_ID}"
      AWS_SECRET_ACCESS_KEY: "${AWS_SECRET_ACCESS_KEY}"
      BACKUP_FILENAME: "backup-{{ .ID }}-{{ .Timestamp }}.tar.gz"
      BACKUP_RETENTION_DAYS: 14
      BACKUP_STOP_CONTAINER_LABEL: "backup.stop-during-backup=true"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - your_volume_name:/backup_sources/your_volume_name:ro
      - /var/lib/docker-volume-backup:/archive

Предварительные условия: установленные Docker и Docker Compose, доступ к S3-совместимому хранилищу и ключи с правами на нужный бакет.

AWS_ACCESS_KEY_ID=YCAJE...
AWS_SECRET_ACCESS_KEY=YCPM7...

Справочник переменных окружения

  • Обязательные: BACKUP_SOURCES, AWS_S3_BUCKET_NAME, AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY. Также нужен том, смонтированный в путь, указанный в BACKUP_SOURCES.
  • Для расписания и именования: BACKUP_CRON_EXPRESSION задает cron-расписание, а BACKUP_FILENAME — имя архива.
  • Для хранения: BACKUP_RETENTION_DAYS задает срок хранения архивов. Дополнительная политика может задаваться через BACKUP_PRUNE_STRATEGY.
  • Для консистентности: BACKUP_STOP_CONTAINER_LABEL определяет label backup.stop-during-backup=true для контейнеров, которые нужно остановить на время операции.
  • Зависит от провайдера: AWS_ENDPOINT обязателен для Yandex Cloud и MinIO, а для AWS S3 его можно не указывать.
  • Для уведомлений: NOTIFICATION_URLS используется для отправки уведомлений в Healthchecks.io или через Telegram-бота.

Как настроить бэкап Docker Volumes в Yandex Cloud Object Storage и MinIO

  • Yandex Cloud Object Storage: AWS_ENDPOINT=https://storage.yandexcloud.net. Ключ сервисного аккаунта должен иметь права storage.editor на бакет.
  • MinIO: AWS_ENDPOINT=http://minio.example.com:9000. Укажите адрес и порт вашего сервера.
  • AWS S3: AWS_ENDPOINT можно не указывать, используется значение по умолчанию.

Создайте отдельный IAM-ключ или сервисный аккаунт с минимальными правами: PutObject, GetObject, ListBucket и DeleteObject для конкретного бакета. Политику жизненного цикла в S3 можно использовать вместе с BACKUP_RETENTION_DAYS для удаления старых архивов.

Где работает cron: контейнер и хост

В контейнере docker-volume-backup работает встроенный cron-демон. Он запускает бэкап по значению BACKUP_CRON_EXPRESSION, поэтому отдельная запись в cron хоста для этого сценария не требуется.

Если расписание должно управляться централизованно на уровне сервера, используйте cron хоста. В этом случае добавьте запись через crontab -e:

0 2 * * * docker exec volume_backup backup > /var/log/docker-backup.log 2>&1

Не включайте одновременно встроенный cron и cron хоста без необходимости: это может запустить два бэкапа. Логи контейнера по умолчанию выводятся в stdout. Для анализа можно использовать journald и journalctl -u docker.service, писать вывод cron хоста в файл или настроить NOTIFICATION_URLS.

Риски копирования томов и требования к бэкапу

Прямое копирование файлов тома с хоста во время изменения данных не гарантирует целостное состояние. Для stateful-приложений архив может содержать файлы из разных моментов времени и не восстановиться корректно.

  • Консистентность данных: архив должен отражать целостное состояние на момент создания бэкапа.
  • Автоматизация: процесс должен выполняться по расписанию без ручного вмешательства.
  • Хранение вне хоста (off-site): копии должны находиться в удаленном хранилище, например S3.
  • Восстановление: процедура должна быть документирована, протестирована и выполняться понятным набором команд.

Для баз данных дополнительно используйте дампы или согласованную остановку приложения. Label backup.stop-during-backup=true позволяет обозначить контейнеры, которые должны быть остановлены во время операции, если такой режим необходим.

Сравнение стратегий резервного копирования Docker Volumes

Ручное архивирование для некритичных данных

Для одноразовых операций, нечастых ручных бэкапов или статического контента подойдет временный контейнер:

docker run --rm \
  -v my_app_data:/data \
  -v /backup:/backup \
  alpine tar czf /backup/backup_$(date +%Y%m%d).tar.gz -C /data .
  • --rm удаляет контейнер после выполнения.
  • -v my_app_data:/data монтирует целевой том.
  • -v /backup:/backup сохраняет архив в директории хоста.
  • alpine tar czf ... использует минимальный образ Alpine Linux для архивации.

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

Почему docker-volume-backup удобен для автоматизации

  • Бэкап без остановки контейнера: подходит для сценариев, где приложение и файловая система допускают копирование без остановки; для СУБД требуется отдельная проверка консистентности.
  • Инкрементальные архивы и дедупликация: могут сокращать объем хранения и сетевой трафик.
  • Поддержка бэкендов: AWS S3, S3-совместимые хранилища Yandex Cloud и MinIO, WebDAV, SFTP и другие.
  • Шифрование и уведомления: доступны настройки шифрования архивов и уведомлений.
  • Встроенный планировщик (cron): расписание задается переменной окружения.

Инкрементальный бэкап и экономия ресурсов

docker-volume-backup может использовать инкрементальную стратегию: при запуске сохраняются изменения относительно предыдущего состояния. Это уменьшает объем временных файлов и сетевой трафик при больших томах.

Политика хранения настраивается через BACKUP_RETENTION_DAYS или BACKUP_PRUNE_STRATEGY. Перед внедрением проверьте выбранный режим на тестовом томе: цепочка инкрементальных архивов должна восстанавливаться в вашей версии инструмента и в вашем S3-хранилище.

Восстановление Docker Volumes

Бэкап считается рабочим только после проверки восстановления. Перед распаковкой остановите приложение, которое использует целевой том, и убедитесь, что архив загружен полностью.

Восстановление на тот же хост

  1. Остановите контейнер приложения, чтобы он не изменял данные во время распаковки.
  2. Создайте новый том или очистите подготовленный том:
docker volume create restored_data
  1. Распакуйте архив через временный контейнер:
docker run --rm \
  -v restored_data:/data \
  -v /backup:/backup \
  alpine sh -c "cd /data && tar xzf /backup/backup_20250402.tar.gz"
  1. Запустите приложение с томом restored_data и проверьте доступность данных.

Восстановление на новый хост

  1. Подготовьте хост: установите Docker и Docker Compose, сохраните docker-compose.yml и настройте доступ к S3 через AWS CLI или аналогичный инструмент.
  2. Загрузите архив:
aws s3 cp s3://your-backup-bucket/backup-your_volume_name-2026-04-01T02-00-00.tar.gz ./ --endpoint-url=https://storage.yandexcloud.net
  1. Создайте том и распакуйте данные:
docker volume create your_volume_name
docker run --rm \
  -v your_volume_name:/data \
  -v $(pwd):/backup \
  alpine sh -c "cd /data && tar xzf /backup/backup-your_volume_name-2026-04-01T02-00-00.tar.gz"
  1. Запустите приложение: разверните контейнеры через сохраненный docker-compose.yml или команды docker run, указав your_volume_name как источник данных.

Типичные ошибки восстановления

  • Permission denied: файлы могут иметь другой UID/GID. При необходимости добавьте к команде распаковки && chown -R 999:999 /data, где 999 — UID пользователя в контейнере.
  • Несовместимость версий: поддерживайте совместимые версии Docker и регулярно тестируйте восстановление на тестовом стенде.
  • Нет доступа к S3: проверьте сетевую связность, firewall, endpoint и credentials.

Как проверить результат бэкапа и восстановления

  • Проверьте код завершения ручной команды docker exec volume_backup backup и логи контейнера.
  • Убедитесь, что архив появился в нужном S3-бакете и его размер соответствует ожидаемому объему данных.
  • Проверьте архив локально командой tar tzf имя_архива.tar.gz, не распаковывая его в рабочий том.
  • Восстановите копию в отдельный том на тестовом хосте и сравните список файлов, права, владельцев и доступность данных приложению.
  • Для баз данных выполните штатную проверку целостности и тестовый запуск приложения после восстановления.

Принципы хранения данных Docker Volumes

Docker Volumes — это абстракция над директорией на хосте. По умолчанию именованные тома хранятся в /var/lib/docker/volumes/. Для тома postgres_data данные находятся в /var/lib/docker/volumes/postgres_data/_data.

Прямое изменение файлов в _data с хоста может привести к конфликтам с операциями контейнера и повреждению данных. Используйте Docker CLI или API либо специализированные инструменты, такие как docker-volume-backup.

Чеклист внедрения

  1. Скопируйте готовый docker-compose.yml и измените имя тома, endpoint и имя бакета.
  2. Настройте файл .env с ключами доступа к S3-совместимому хранилищу.
  3. Запустите службу: docker-compose up -d.
  4. Проверьте бэкап: docker exec volume_backup backup, логи и наличие архива в бакете.
  5. Проверьте архив и восстановление: выполните tar tzf и тестовую распаковку в отдельный том.
  6. Регулярно тестируйте восстановление на новый хост и обновляйте процедуру при изменении приложения или инфраструктуры.

Дополнительные команды для безопасного удаления Docker сетей и томов приведены в руководстве по очистке Docker.

Поделиться:
Сохранить гайд? В закладки браузера