Как зарезервировать Docker-контейнер MySQL (2026)
Правильный способ зарезервировать контейнер MySQL — логический дамп, а не копия файлов. Выполните `mysqldump --all-databases --single-transaction --routines --triggers -uroot -p"$MYSQL_ROOT_PASSWORD"` внутри контейнера и зарезервируйте его вывод. Копирование /var/lib/mysql, пока MySQL пишет, даёт несогласованный снимок; --single-transaction оборачивает дамп в одну транзакцию InnoDB, захватывая все таблицы в единой согласованной точке без блокировки записи.
Что находит Dockstash
| Найденные переменные окружения | MYSQL_ROOT_PASSWORD, MYSQL_DATABASE, MYSQL_USER, MYSQL_PASSWORD |
|---|---|
| Порт по умолчанию | 3306 |
| Живые пути данных (никогда не копируются вживую) | /var/lib/mysql |
| Примеры образов | mysql:8, mysql:8.0, mysql:5.7, mysql |
Резервируем MySQL с Dockstash, шаг за шагом
Создайте аккаунт Dockstash и откройте панель
Зарегистрируйтесь бесплатно на app.dockstash.com/register. Одноразовый мастер настройки спросит ваш VPS для хранения (машину, где будут лежать зашифрованные резервные копии) и сгенерирует пароль шифрования — сразу сохраните его в менеджере паролей: он показывается ровно один раз.
Добавьте Docker-проект, в котором работает MySQL
На экране Projects Dockstash автоматически находит каждую папку Compose-проекта на сервере (по умолчанию под /var/www). Выберите проект с вашим сервисом MySQL. Пока ничего не резервируется — вы лишь указываете Dockstash, где живёт проект.
Проверьте, что MySQL распознан
Откройте проект и вкладку Plan. Dockstash читает docker-compose.yml, распознаёт образ mysql и добавляет слой базы с правильной командой дампа — плюс имя контейнера и найденные переменные (MYSQL_ROOT_PASSWORD, MYSQL_DATABASE, MYSQL_USER, MYSQL_PASSWORD). Файлы, базы и конфиги прокси можно переключать перед сохранением.
Опционально: проверьте дамп вручную
Если хотите доказательство до автоматизации, выполните тот же дамп, что выполнит Dockstash. Вы увидите поток SQL — CREATE DATABASE, CREATE TABLE и INSERT. Этот вывод и резервируется, никогда не живой каталог /var/lib/mysql.
docker exec <mysql-container> sh -c 'mysqldump --all-databases --single-transaction -uroot -p"$MYSQL_ROOT_PASSWORD"' | head -n 20Подтвердите место хранения
Резервные копии хранятся как зашифрованные снимки restic на вашем собственном VPS для хранения, по SSH. Если вы прошли мастер настройки, всё уже настроено; хост, пользователя, порт или SSH-ключ можно изменить в любой момент в Settings → Storage.
Настройте расписание резервного копирования
Во вкладке Schedule выберите ежедневно, еженедельно или собственный cron (валидируется при вводе). Ежедневно в тихий час — правильное умолчание для большинства проектов MySQL. Добавьте еженедельный prune с политикой хранения.
Запустите первую копию сейчас
Нажмите Backup Now. Dockstash выполнит mysqldump с --single-transaction, --routines и --triggers внутри контейнера и отправит дамп прямо в restic — живой вывод смотрите в панели логов.
Убедитесь, что снимок существует
По завершении запуска карточка проекта показывает новое время последней копии, число снимков и размер репозитория. Откройте экран Snapshots: точка восстановления появится на таймлайне — это ваше доказательство, что копия дошла до внешнего хранилища.
Команда дампа
mysqldump --all-databases --single-transaction --routines --triggers -uroot -p"$MYSQL_ROOT_PASSWORD"Команда восстановления
mysql -uroot -p"$MYSQL_ROOT_PASSWORD"--single-transaction оборачивает дамп в одну транзакцию InnoDB, захватывая все таблицы в единой согласованной точке без блокировки записи.
Восстановите копию MySQL и докажите, что она работает
Резервная копия MySQL становится настоящей только после восстановления. Восстановления Dockstash по умолчанию не перезаписывают живую базу — сначала в новое место, проверка данных, затем осознанное продвижение.
Выберите точку восстановления
Откройте Snapshots, выберите проект и просмотрите таймлайн. Каждая строка — полный дамп всех баз сервера на один момент времени — схемы, данные, процедуры и триггеры — плюс файлы проекта того же запуска.
Восстановите в новое место
Нажмите Restore и оставьте режим по умолчанию «Restore to new location». Введите имя проекта для подтверждения — осознанное действие с набором текста. Дамп и файлы попадут в выбранный целевой путь, не трогая живой проект.
Проверьте восстановленные данные
Загрузите дамп в тестовый контейнер MySQL, выполните SHOW DATABASES, чтобы убедиться, что каждая схема вернулась, и выборочно проверьте таблицы приложения. Счётчики строк и свежие записи — самый быстрый тест.
docker exec <mysql-container> sh -c 'mysql -uroot -p"$MYSQL_ROOT_PASSWORD" -e "SHOW DATABASES;"'Продвигайте, когда всё проверено
Когда восстановленные данные проверены, переключите на них приложение (или повторите восстановление в режиме «Overwrite existing» — явный опт-ин). Ещё лучше: пусть еженедельная тренировка восстановления делает это доказательство автоматически, чтобы восстановление никогда не было вашей первой репетицией.
Каких ловушек избегать
- Никогда не запускайте restic по живому каталогу /var/lib/mysql — табличные пространства InnoDB, скопированные посреди записи, несогласованы и провалят восстановление.
- --single-transaction даёт согласованный снимок только транзакционным (InnoDB) таблицам; MyISAM не покрыт и требует блокировки.
- Добавляйте --routines и --triggers, иначе хранимые процедуры и триггеры молча выпадут из дампа.
Типичные проблемы резервирования MySQL
- Симптом
- Дамп падает с «Access denied for user 'root'@'localhost'».
- Причина
- MYSQL_ROOT_PASSWORD в compose больше не совпадает с паролем внутри тома данных — переменная задаёт пароль только при первой инициализации; поздние изменения в compose не влияют на существующий том.
- Решение
- Используйте пароль, с которым инициализировался том, или сбросьте root-пароль внутри контейнера, затем выровняйте env compose.
- Симптом
- Дамп завершается, но часть таблиц после восстановления несогласована.
- Причина
- Это таблицы MyISAM. --single-transaction гарантирует согласованный снимок только для транзакционных таблиц InnoDB; MyISAM читается вне этой гарантии.
- Решение
- Проверьте движок через SHOW TABLE STATUS. Мигрируйте MyISAM в InnoDB (ALTER TABLE ... ENGINE=InnoDB) — долговечное решение — или примите краткую блокировку с --lock-tables.
- Симптом
- Восстановление в тестовый контейнер даёт «Unknown collation: utf8mb4_0900_ai_ci».
- Причина
- Дамп из MySQL 8.x, а восстанавливаете в образ 5.7; коллации по умолчанию 8.0 не существуют в старых серверах.
- Решение
- Восстанавливайте в ту же мажорную версию, из которой дамп (например mysql:8). Старые дампы в новые серверы работают; наоборот — часто нет.
- Симптом
- Запуск резервного копирования падает с устаревшей блокировкой restic после сбоя или перезагрузки.
- Причина
- Предыдущая задача умерла посреди запуска и оставила репозиторий заблокированным.
- Решение
- Вручную делать ничего не нужно: следующий запуск обнаружит осиротевшую блокировку и автоматически выполнит restic unlock. Если запуски продолжают падать, посмотрите настоящую ошибку в панели живых логов.
Сделайте это в один клик с Dockstash
Dockstash выполняет ровно тот дамп, что выше, передаёт его restic вовне и автоматически проверяет восстановление тренировкой — без скриптов на поддержке.
Последнее обновление: July 2026
Часто задаваемые вопросы
Почему важен --single-transaction?
Без него mysqldump читает таблицы по одной, и запись между таблицами даёт несогласованный дамп. --single-transaction оборачивает всё в одну транзакцию InnoDB: весь дамп отражает один момент времени, без блокировки записи.
Включает ли дамп хранимые процедуры и триггеры?
Только с --routines и --triggers, которые Dockstash передаёт. mysqldump по умолчанию их опускает — частая причина «восстановленной, но сломанной» базы.
Можно ли резервировать MySQL копированием /var/lib/mysql?
Нет. Табличное пространство InnoDB и redo-логи пишутся непрерывно; копия файлов посреди записи несогласована. Вместо этого Dockstash выполняет mysqldump внутри контейнера.
А если у меня таблицы MyISAM?
--single-transaction не делает MyISAM согласованным — движок не транзакционный. Если вы зависите от MyISAM, нужна краткая блокировка (--lock-tables); долговечное решение — миграция этих таблиц в InnoDB.
Как часто резервировать MySQL?
Ежедневно — практичный вариант по умолчанию; ежечасно — если потеря дня записей недопустима. На тарифе Free копии только вручную; Pro позволяет расписания вплоть до ежечасных, Business — любой cron. Сочетайте расписание с еженедельной тренировкой восстановления.
Где на самом деле живут резервные копии?
На вашем собственном VPS для хранения, как зашифрованные снимки restic, отправляемые по SSH. Dockstash никогда не держит ваши данные в чужом облаке — вы указываете машину под вашим контролем, а репозиторий зашифрован паролем, который есть только у вас.
Как узнать, что копия восстановима, без ручного восстановления?
Запланируйте тренировку восстановления. Dockstash восстанавливает последний снимок в изолированную рабочую область, сверяет каждый файл по байтам с источником и проверяет восстановленный дамп — затем ставит на проект значок «прошло/провалено». Еженедельная тренировка означает всегда свежее доказательство.