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