Настройка резервного копирования Docker volumes с Restic

Настройка бэкапирования Docker volumes

Представьте: вы администрируете GitLab на Docker. Кто-то случайно выполняет docker-compose down -v и все базы данных с issues, wiki, merge requests исчезают. Или хост выходит из строя, а последний бэкап сделан вручную месяц назад. Без автоматического бэкапа вы теряете часы работы и доверие команды. Чтобы этого избежать, мы внедряем резервное копирование Docker volumes с Restic — быстрым бэкап-инструментом, который делает инкрементальные, дедуплицированные и шифрованные снапшоты.

Restic использует криптографию AES-256-GCM и поддерживает S3, Backblaze B2, SFTP и локальные папки. Это Go-бинарник, который запускается без зависимостей. Дедупликация на уровне блоков размером 4 МБ позволяет экономить до 90% места при бэкапе нескольких схожих томов. Ниже разберем, как мы настраиваем бэкап для docker-compose и Kubernetes, и почему проверка восстановления — не опция, а обязательный этап.

Основные проблемы, которые мы решаем

• Отсутствие автоматизации: бэкапы делаются руками или не делаются вовсе. Мы настраиваем systemd timer или Kubernetes CronJob, чтобы они запускались ежедневно.
• Бэкапы хранятся на том же хосте: при отказе диска они теряются. Мы отправляем копии в объектное хранилище (S3, Selectel, Yandex Object Storage).
• Нет проверки восстановления: бэкап считается исправным, пока не понадобится. Мы автоматически запускаем restic check и раз в неделю разворачиваем staging с восстановлением.
• Для баз данных — бэкап томов без остановки БД ведёт к повреждению данных. Используем дампы через pg_dump, mysqldump или mongodump.

Почему Restic лучше rsync или duplicity?

Restic выигрывает за счет дедупликации, скорости и простоты. rsync не шифрует данные на лету, duplicity медленнее на инкрементах. Сравнение по ключевым параметрам:

Для Docker volumes Restic — оптимальный выбор. По нашим тестам, он быстрее duplicity в 2-3 раза при инкрементальном бэкапе томов объемом 100 ГБ.

Как автоматизировать бэкап Docker volumes?

Базовый сценарий для одного volume

Для бэкапа тома PostgreSQL запускаем временный контейнер с образом restic/restic, монтируя том в режиме read-only:

docker run --rm \
 -v postgres_data:/data:ro \
 -v restic-cache:/root/.cache/restic \
 -e RESTIC_REPOSITORY=s3:s3.amazonaws.com/my-bucket/docker-backups \
 -e RESTIC_PASSWORD=supersecret \
 -e AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID \
 -e AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY \
 restic/restic backup /data --tag postgres_data

Опция :ro гарантирует, что контейнер не повредит данные. Для PostgreSQL правильнее использовать pg_dump внутри работающего контейнера:

docker exec postgres_container pg_dump -U dbuser dbname \
| restic backup --stdin --stdin-filename postgres.sql \
  --tag postgres --tag daily

Этот подход избегает inconsistent state, который может возникнуть при бэкапе raw-тома работающей БД.

Автоматизация через systemd timer

1. Создайте service-файл /etc/systemd/system/docker-backup.service:

   [Unit]
   Description=Docker volumes backup via Restic
   After=docker.service
   
   [Service]
   Type=oneshot
   EnvironmentFile=/etc/docker-backup.env
   ExecStart=/usr/local/bin/backup-volumes.sh

   В Kubernetes аналогичная логика через CronJob с образом restic/restic и монтированием нужных PVC в read-only.

   Как проверить, что бэкап рабочий?

   Мы включаем в процедуру автоматическую проверку восстановления. После каждого бэкапа запускается restic check — он проверяет целостность репозитория. Раз в неделю в staging разворачивается тестовая база и выполняется pg_restore. Только после успешного восстановления бэкап считается валидным. Статистика: около 12% бэкапов в среднем по рынку оказываются нерабочими при первой проверке.

   Также настраиваем оповещения через healthchecks.io или Telegram бота. Если бэкап не выполнился или проверка восстановления упала, вы получаете алерт в течение 5 минут.

   Что входит в настройку

   Шаг	Длительность	Описание
   Настройка Restic и репозитория	2-3 часа	Установка, инициализация, настройка хранилища S3
   Написание скриптов бэкапа	1-2 часа	Bash-скрипт с поддержкой нескольких volumes (файловые + дампы БД)
   Настройка планировщика	1 час	Systemd timer или Kubernetes CronJob
   Проверка восстановления	1 час	Тест restore на staging с фиксацией метрик
   Документация	1 час	Описание процедуры восстановления, runbook
   Мониторинг и оповещения	0.5 часа	Интеграция с healthchecks.io или Prometheus

   В результате вы получаете:

   • Рабочие скрипты бэкапа для всех Docker volumes сервисов.
   • Настроенный планировщик (systemd timer или Kubernetes CronJob).
   • Хранилище в S3 (или другом облаке) с шифрованием AES-256-GCM.
   • Документацию по восстановлению: команды restore, проверка целостности.
   • Оповещения о неудачных бэкапах.
   • Ротацию снапшотов: keep daily 7, weekly 4, monthly 6 с --prune.
   Пример полного скрипта бэкапа всех volumes

   #!/bin/bash
   REPOSITORY="s3:s3.amazonaws.com/my-bucket/docker-backups"
   PASSWORD="supersecret"
   export AWS_ACCESS_KEY_ID=...
   export AWS_SECRET_ACCESS_KEY=...
   # Backup each volume
   for volume in $(docker volume ls -q); do
       docker run --rm -v $volume:/data:ro restic/restic backup /data --tag $volume --repo $REPOSITORY --password $PASSWORD
   done

   Сроки

   Для типового стека из 3-5 сервисов (docker-compose или Kubernetes) настройка занимает один рабочий день. Если есть нестандартные volumes или специфические БД (MongoDB, ClickHouse), добавляется исследование — но не более двух дней.

   Получите консультацию — оценим вашу инфраструктуру и предложим решение. Опыт: более 5 лет в DevOps, 30+ проектов по резервному копированию. Свяжитесь с нами — настроим бэкап, который будет работать.