Налаштування бекапу 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+ проектів з резервного копіювання. Зв'яжіться з нами — налаштуємо бекап, який буде працювати.