Скопируйте эти команды для немедленного создания резервной копии PostgreSQL или MySQL в Docker. Готовые скрипты для cron, инструкции по восстановлению и сравнение методов для production.
В этой статье вы найдете: готовые команды для экстренного копирования, скрипты для автоматизации через cron, пошаговые инструкции по восстановлению данных после сбоя и подробное сравнение методов (дампинг vs volumes) для production-среды.
Мы разберем два основных подхода: логические дампы через pg_dump/mysqldump и файловые копии через volumes. Каждый метод имеет свои преимущества для разных сценариев. В статье приведены конкретные команды Docker, примеры скриптов и инструкции по восстановлению данных после сбоя.
Быстрый старт: 3 команды для немедленного бэкапа
Скопируйте и выполните — это займет меньше минуты.
- PostgreSQL (логический дамп):
docker exec -e PGPASSWORD=your_password -t postgres_container pg_dump -U postgres -d database_name -F c -f /tmp/backup.dump && docker cp postgres_container:/tmp/backup.dump ./backup_$(date +%Y%m%d_%H%M%S).dump - MySQL/MariaDB (логический дамп):
docker exec -e MYSQL_PWD=secret mysql_container mysqldump -u root --single-transaction --routines --events database_name > /tmp/backup.sql && docker cp mysql_container:/tmp/backup.sql ./mysql_backup_$(date +%Y%m%d_%H%M%S).sql - Полный снепшот Docker Volume (файловая копия):
docker run --rm -v postgres_data:/data -v $(pwd):/backup alpine tar czf /backup/postgres_volume_$(date +%Y%m%d).tar.gz -C /data .
Зачем резервное копирование в Docker — это не только про volumes
Docker volumes обеспечивают сохранность данных между перезапусками контейнеров, но не защищают от повреждения файлов, ошибок приложения или сбоя хоста. Volume привязан к конкретному хосту Docker. Если хост выходит из строя, данные в volume становятся недоступными.
Для построения отказоустойчивой системы нужна стратегия резервного копирования, которая включает:
- Логические дампы через pg_dump (PostgreSQL) и mysqldump (MySQL) — создают переносимые SQL-файлы
- Файловые копии volumes — сохраняют полное состояние кластера БД
- Автоматизацию через cron — обеспечивает регулярное создание бэкапов
- Хранение вне хоста — защищает от физического сбоя сервера
Эта статья охватывает оба подхода с готовыми командами для каждого сценария.
Готовые команды для быстрого резервного копирования
Эти команды можно скопировать и запустить немедленно. Они работают с контейнерами PostgreSQL и MySQL, запущенными через Docker.
Резервная копия PostgreSQL с помощью pg_dump
Для создания дампа работающего контейнера PostgreSQL используйте команду docker exec:
docker exec -t postgres_container pg_dump -U postgres -d database_name -F c -b -v -f /tmp/backup.dumpКлючевые флаги pg_dump:
- -F c — формат custom, поддерживает сжатие и параллельное восстановление
- -b — включает большие объекты (BLOBs)
- -v — подробный вывод для отладки
- --clean — добавляет команды DROP перед CREATE (для чистого восстановления)
- --if-exists — использует IF EXISTS с DROP для избежания ошибок
- --no-owner — не устанавливает владельца объектов при восстановлении
Для безопасной передачи пароля используйте переменную окружения PGPASSWORD:
docker exec -e PGPASSWORD=your_password -t postgres_container pg_dump -U postgres -d database_name -F c -f /tmp/backup.dumpАльтернативный вариант — запуск временного контейнера с доступом к сети основного:
docker run --rm --network container:postgres_container -e PGPASSWORD=your_password postgres:15 pg_dump -h localhost -U postgres -d database_name -F c > backup.dumpЧтобы скопировать дамп с контейнера на хост:
docker cp postgres_container:/tmp/backup.dump ./backup_$(date +%Y%m%d_%H%M%S).dumpРезервная копия MySQL/MariaDB с помощью mysqldump
Для контейнера MySQL команда создания дампа через docker exec:
docker exec mysql_container mysqldump -u root -psecret --single-transaction --routines --events --databases database_name > /tmp/backup.sqlВажные флаги mysqldump:
- --single-transaction — создает консистентный снимок для InnoDB таблиц
- --routines — включает хранимые процедуры и функции
- --events — включает события планировщика
- --databases — указывает базы данных для резервирования
- --all-databases — резервирует все базы данных
Передача пароля через переменную MYSQL_PWD (с оговоркой о безопасности):
docker exec -e MYSQL_PWD=secret mysql_container mysqldump -u root --single-transaction database_name > /tmp/backup.sqlБолее безопасный подход — использование конфигурационного файла:
docker exec mysql_container mysqldump --defaults-file=/etc/mysql/backup.cnf --single-transaction database_name > /tmp/backup.sqlДля копирования дампа на хост:
docker cp mysql_container:/tmp/backup.sql ./mysql_backup_$(date +%Y%m%d_%H%M%S).sqlСоздание резервной копии через копирование файлов данных (Volumes)
Этот метод подходит для создания полных снепшотов кластера БД, включая системные каталоги. Он работает быстрее для больших баз данных, но требует остановки БД или работает только для неактивных данных.
Использование docker cp для копирования директории данных:
docker cp postgres_container:/var/lib/postgresql/data ./postgres_data_backupВажно: этот метод копирует файлы, которые могут быть в неконсистентном состоянии, если БД активна. Для консистентной копии нужно остановить контейнер перед выполнением команды.
Архивация Docker Volume с помощью утилиты tar
Создание переносимого архива всего volume через временный контейнер:
docker run --rm -v postgres_data:/data -v $(pwd):/backup alpine tar czf /backup/postgres_volume_$(date +%Y%m%d).tar.gz -C /data .Пояснение команды:
- --rm — удаляет контейнер после завершения
- -v postgres_data:/data — монтирует volume postgres_data в /data контейнера
- -v $(pwd):/backup — монтирует текущую директорию хоста в /backup
- alpine — минимальный образ Linux с утилитой tar
- tar czf — создает сжатый архив в формате gzip
- -C /data . — указывает исходную директорию для архивации
Эта команда сохраняет права доступа файлов и создает готовый архив для хранения или переноса.
Сравнение методов: логические дампы vs копирование volumes
| Критерий | pg_dump / mysqldump | Копирование volumes (tar) |
|---|---|---|
| Скорость | Медленнее на больших БД | Быстрее, копирует файлы как есть |
| Переносимость | Высокая (между версиями СУБД) | Низкая (привязка к версии СУБД) |
| Риски | Нагрузка на CPU, не все объекты могут попасть в дамп | Требует остановки БД для консистентности |
| Размер бэкапа | Меньше за счет сжатия | Больше (полная копия данных) |
| Сценарий | Регулярные бэкапы, миграция, тестирование | Полные снепшоты, аварийное восстановление, клонирование |
Восстановление данных из резервной копии: пошаговые сценарии
Восстановление данных — критическая операция при сбоях. Эти инструкции покрывают основные сценарии восстановления.
Восстановление из дампа PostgreSQL
Для восстановления из plain-дампа (SQL-файла):
docker exec -i postgres_container psql -U postgres -d database_name < backup.sqlДля восстановления из custom-формата с использованием pg_restore:
docker exec -i postgres_container pg_restore -U postgres -d database_name -v /tmp/backup.dumpСоздание новой базы данных перед восстановлением:
docker exec postgres_container psql -U postgres -c "CREATE DATABASE new_database;"
docker exec -i postgres_container pg_restore -U postgres -d new_database -v /tmp/backup.dumpВосстановление в временный контейнер для проверки:
docker run --name test_restore -e POSTGRES_PASSWORD=secret -d postgres:15
docker cp backup.dump test_restore:/tmp/
docker exec test_restore pg_restore -U postgres -d postgres -v /tmp/backup.dumpВосстановление из дампа MySQL
Восстановление SQL-дампа в существующую базу данных:
docker exec -i mysql_container mysql -u root -psecret database_name < backup.sqlСоздание базы данных и восстановление:
docker exec mysql_container mysql -u root -psecret -e "CREATE DATABASE restored_db;"
docker exec -i mysql_container mysql -u root -psecret restored_db < backup.sqlДля восстановления процедур и триггеров убедитесь, что дамп создан с флагами --routines и --events.
Восстановление из копии файлов Volume
Восстановление архива volume в новый или существующий volume:
- Остановите контейнер, использующий volume:
docker stop postgres_container - Создайте временный контейнер для распаковки:
docker run --rm -v postgres_data:/data -v $(pwd):/backup alpine sh -c "rm -rf /data/* && tar xzf /backup/postgres_volume.tar.gz -C /data" - Запустите контейнер с восстановленным volume:
docker start postgres_container
Важно: команда rm -rf /data/* удаляет все существующие данные в volume. Убедитесь, что архив корректен перед выполнением.
Для безопасного восстановления в новый volume:
docker volume create postgres_data_restored
docker run --rm -v postgres_data_restored:/data -v $(pwd):/backup alpine tar xzf /backup/postgres_volume.tar.gz -C /data
docker run --name postgres_restored -v postgres_data_restored:/var/lib/postgresql/data -e POSTGRES_PASSWORD=secret -d postgres:15Автоматизация резервного копирования: скрипты и cron
Ручное создание бэкапов ненадежно. Автоматизация через cron обеспечивает регулярное резервное копирование без вмешательства администратора.
Пример скрипта для автоматического бэкапа PostgreSQL
#!/bin/bash
# Конфигурация
CONTAINER_NAME="postgres_container"
DB_NAME="production_db"
BACKUP_DIR="/var/backups/postgres"
RETENTION_DAYS=30
# Создание директории для бэкапов
mkdir -p "$BACKUP_DIR"
# Имя файла с timestamp
BACKUP_FILE="$BACKUP_DIR/pg_backup_$(date +%Y%m%d_%H%M%S).dump"
# Создание дампа
docker exec -e PGPASSWORD="$DB_PASSWORD" "$CONTAINER_NAME" \
pg_dump -U postgres -d "$DB_NAME" -F c -b -v -f "/tmp/current_backup.dump"
# Проверка успешности выполнения
if [ $? -eq 0 ]; then
# Копирование дампа на хост
docker cp "$CONTAINER_NAME:/tmp/current_backup.dump" "$BACKUP_FILE"
# Очистка временного файла в контейнере
docker exec "$CONTAINER_NAME" rm -f "/tmp/current_backup.dump"
# Удаление старых бэкапов
find "$BACKUP_DIR" -name "pg_backup_*.dump" -mtime +$RETENTION_DAYS -delete
echo "$(date): Backup successful: $BACKUP_FILE" >> "$BACKUP_DIR/backup.log"
else
echo "$(date): Backup failed" >> "$BACKUP_DIR/backup.log"
exit 1
fiСкрипт включает проверку кода возврата, ротацию бэкапов и логирование. Для MySQL адаптируйте команды дампа соответствующим образом.
Настройка планировщика задач Cron
Добавьте задание в crontab для ежедневного запуска в 2:00:
0 2 * * * /usr/bin/docker exec postgres_container pg_dump -U postgres -d production_db -F c -f /tmp/backup.dump && /usr/bin/docker cp postgres_container:/tmp/backup.dump /var/backups/postgres/pg_backup_$(date +\%Y\%m\%d).dumpИли используйте bash-скрипт с перенаправлением вывода в лог-файл:
0 2 * * * /opt/scripts/backup_postgres.sh >> /var/log/postgres_backup.log 2>&1Ключевые моменты настройки cron:
- Указывайте полный путь к docker и docker-compose
- Экранируйте символы процента в команде date
- Перенаправляйте stdout и stderr в лог-файл для диагностики
- Устанавливайте правильные переменные окружения в скрипте
Для комплексной автоматизации резервного копирования Docker volumes изучите наше полное руководство по настройке отказоустойчивого бэкапа Docker Volumes с поддержкой инкрементального копирования в S3.
Лучшие практики для production-среды
Базовых команд недостаточно для production. Эти практики помогут построить надежную систему резервного копирования.
Чек-лист для production
- Тестовое восстановление: Проверьте восстановление на чистом контейнере с проверкой целостности данных.
- Стратегия 3-2-1: Храните три копии данных на двух разных типах носителей, одна копия — вне площадки.
- Уведомления об ошибках: Настройте мониторинг cron-заданий через логи, email или системы мониторинга.
- Документированное восстановление: Инструкция должна быть доступна даже при недоступности основной инфраструктуры.
- Проверка целостности: Периодически восстанавливайте бэкап в тестовое окружение для выявления скрытых проблем.
- Ротация бэкапов: Настройте автоматическое удаление старых копий для экономии места.
Для production-развертывания Docker с мониторингом и логированием изучите полное руководство по безопасному деплою Docker в production с health checks и blue-green деплоем.
Резервное копирование — не дополнительная опция, а обязательный компонент инфраструктуры. Начните с простых cron-заданий, постепенно внедряя мониторинг, проверку целостности и хранение вне хоста. Регулярное тестирование восстановления — единственный способ гарантировать работоспособность бэкапов при реальном сбое.