Docker backup — это не просто сохранение контейнера. Для полноценной резервной копии необходимо определить, какие данные приложения нужно восстановить после сбоя.
Особенно важны:
- Docker volumes;
- базы данных;
- конфигурационные файлы;
- Compose-файлы;
- Dockerfile;
- секреты и переменные окружения;
- пользовательские файлы.
Главное правило: контейнер можно пересоздать, данные — нельзя потерять.
Что именно нужно сохранять
Для проекта на Docker рекомендуется иметь копии:
compose.yaml
.env
Dockerfile
конфигураций
volumes
database dumps
При этом .env и другие файлы с секретами должны храниться защищенно.
Backup Docker volume
Допустим, есть volume:
docker volume ls
Пусть его имя:
app-data
Создаем архив:
docker run --rm \
-v app-data:/data \
-v "$PWD:/backup" \
alpine \
tar czf /backup/app-data.tar.gz -C /data .
В текущем каталоге появится:
app-data.tar.gz
Восстановление volume
Создаем volume:
docker volume create app-data
Восстанавливаем:
docker run --rm \
-v app-data:/data \
-v "$PWD:/backup" \
alpine \
tar xzf /backup/app-data.tar.gz -C /data
Backup PostgreSQL
Для PostgreSQL лучше использовать инструменты самой базы.
Например:
docker exec postgres \
pg_dump -U postgres mydatabase \
> backup.sql
Восстановление:
cat backup.sql | docker exec -i postgres \
psql -U postgres mydatabase
Для больших баз и production-инфраструктуры стратегия резервного копирования должна учитывать размер базы, время восстановления, требования к RPO/RTO и особенности PostgreSQL.
Подробнее — в статье «Docker для PostgreSQL».
Backup WordPress
В WordPress необходимо сохранить как минимум:
- базу данных;
- каталог
wp-content; - пользовательские загрузки;
- конфигурацию.
Одна копия файлов без базы недостаточна.
Подробнее — в статье «Docker для WordPress».
Backup Redis
Redis может использовать разные механизмы сохранения данных. Но прежде чем включать резервное копирование, нужно определить, является ли Redis основной базой данных или только кэшем.
Если Redis используется как cache, его потеря может быть приемлемой.
Если в Redis хранятся важные данные, необходимо отдельно настроить persistence и backup.
Подробнее — в статье «Docker для Redis».
Docker commit — это не backup
Команда:
docker commit
создает образ из состояния контейнера.
Это не полноценная резервная копия приложения.
Она не заменяет:
- database dump;
- backup volume;
- backup конфигурации;
- проверенный сценарий восстановления.
Backup Docker Compose проекта
Сохраняйте исходные файлы:
compose.yaml
compose.production.yaml
Dockerfile
.env.example
nginx/
Если конфигурация хранится в Git, это существенно упрощает восстановление инфраструктуры.
Где хранить backup
Не стоит хранить единственную резервную копию на том же сервере, где работает Docker.
Лучше использовать правило:
- несколько копий;
- разные носители;
- отдельная площадка.
Например:
Server
├── Production
└── Local backup
Backup storage
└── Offsite backup
Проверяйте восстановление
Резервная копия, которую никто никогда не восстанавливал, не гарантирует восстановление.
Периодически нужно:
- развернуть чистую среду;
- восстановить backup;
- проверить приложение;
- проверить данные;
- зафиксировать результат.
Backup Swarm
Для Docker Swarm отдельно необходимо сохранять состояние manager-узлов. Docker указывает, что состояние Swarm хранится в /var/lib/docker/swarm/, включая данные, необходимые для восстановления.
Типичные ошибки
Backup только контейнера
Контейнер не равен данным приложения.
Backup только volume
База может требовать отдельного database dump.
Backup на тот же диск
При повреждении диска можно потерять и production, и резервную копию.
Нет теста восстановления
Самая опасная ошибка — обнаружить проблему с backup только во время аварии.
Итог
Docker backup должен быть частью общей стратегии резервного копирования приложения.
Для веб-проекта обычно нужно сохранять:
Код
Конфигурация
Volumes
Database dumps
Секреты
И главное — регулярно проверять восстановление.
Читайте также:


