Как зарезервировать Docker-контейнер MongoDB (2026)
Безопасное резервирование MongoDB сводится к одному правилу: дампить, а не копировать. `mongodump --archive --oplog` даёт согласованный, восстановимый дамп из работающего контейнера, который restic затем шифрует во внешнее хранилище. --oplog записывает операции во время дампа, чтобы mongorestore --oplogReplay восстановил снимок, согласованный на момент времени. Всё, что копирует /data/db вживую, рискует невосстановимой копией.
Что находит Dockstash
| Найденные переменные окружения | MONGO_INITDB_ROOT_USERNAME, MONGO_INITDB_ROOT_PASSWORD, MONGO_INITDB_DATABASE |
|---|---|
| Порт по умолчанию | 27017 |
| Живые пути данных (никогда не копируются вживую) | /data/db |
| Примеры образов | mongo:7, mongo:6, mongo:5, mongo |
Резервируем MongoDB с Dockstash, шаг за шагом
Создайте аккаунт Dockstash и откройте панель
Зарегистрируйтесь бесплатно на app.dockstash.com/register. Одноразовый мастер настройки спросит ваш VPS для хранения (машину, где будут лежать зашифрованные резервные копии) и сгенерирует пароль шифрования — сразу сохраните его в менеджере паролей: он показывается ровно один раз.
Добавьте Docker-проект, в котором работает MongoDB
На экране Projects Dockstash автоматически находит каждую папку Compose-проекта на сервере (по умолчанию под /var/www). Выберите проект с вашим сервисом MongoDB. Пока ничего не резервируется — вы лишь указываете Dockstash, где живёт проект.
Проверьте, что MongoDB распознана
Откройте проект и вкладку Plan. Dockstash читает docker-compose.yml, распознаёт образ mongo и добавляет слой базы с правильной командой дампа — плюс имя контейнера и найденные переменные (MONGO_INITDB_ROOT_USERNAME, MONGO_INITDB_ROOT_PASSWORD, MONGO_INITDB_DATABASE). Файлы, базы и конфиги прокси можно переключать перед сохранением.
Опционально: проверьте дамп вручную
Если хотите доказательство до автоматизации, выполните тот же дамп — mongodump пишет единый архив в stdout, перенаправленный в счётчик байтов. Большое ненулевое число байтов — доказательство, что архив течёт чисто. Именно этот архив и резервируется, никогда не живой каталог /data/db.
docker exec <mongo-container> sh -c 'mongodump --archive --oplog' | wc -cПодтвердите место хранения
Резервные копии хранятся как зашифрованные снимки restic на вашем собственном VPS для хранения, по SSH. Если вы прошли мастер настройки, всё уже настроено; хост, пользователя, порт или SSH-ключ можно изменить в любой момент в Settings → Storage.
Настройте расписание резервного копирования
Во вкладке Schedule выберите ежедневно, еженедельно или собственный cron (валидируется при вводе). Ежедневно в тихий час — правильное умолчание для большинства проектов MongoDB. Добавьте еженедельный prune с политикой хранения.
Запустите первую копию сейчас
Нажмите Backup Now. Dockstash выполнит mongodump с --archive и --oplog внутри контейнера и отправит архив прямо в restic — живой вывод смотрите в панели логов.
Убедитесь, что снимок существует
По завершении запуска карточка проекта показывает новое время последней копии, число снимков и размер репозитория. Откройте экран Snapshots: точка восстановления появится на таймлайне — это ваше доказательство, что копия дошла до внешнего хранилища.
Команда дампа
mongodump --archive --oplogКоманда восстановления
mongorestore --archive --oplogReplay --drop--oplog записывает операции во время дампа, чтобы mongorestore --oplogReplay восстановил снимок, согласованный на момент времени.
Восстановите копию MongoDB и докажите, что она работает
Резервная копия MongoDB становится настоящей только после восстановления. Восстановления Dockstash по умолчанию не перезаписывают живую базу — сначала в свежий staging, там воспроизводится архив, проверяются данные, затем осознанное продвижение.
Выберите точку восстановления
Откройте Snapshots, выберите проект и просмотрите таймлайн. Каждая строка — полный архив mongodump — все базы и коллекции плюс записи oplog, снятые во время дампа — вместе с файлами проекта того же запуска.
Восстановите в новое место
Нажмите Restore и оставьте режим по умолчанию «Restore to new location». Введите имя проекта для подтверждения — осознанное действие с набором текста. Дамп и файлы попадут в выбранный целевой путь, не трогая живой проект.
Проверьте восстановленные данные
В тестовом контейнере перечислите базы через mongosh, убедитесь, что каждая вернулась, и выборочно проверьте коллекции приложения. Счётчики документов и свежие записи — самый быстрый тест.
docker exec <mongo-container> mongosh --quiet --eval "db.adminCommand({ listDatabases: 1 })"Продвигайте, когда всё проверено
Когда восстановленные данные проверены, переключите на них приложение (или повторите восстановление в режиме «Overwrite existing» — явный опт-ин). Ещё лучше: пусть еженедельная тренировка восстановления делает это доказательство автоматически, чтобы восстановление никогда не было вашей первой репетицией.
Каких ловушек избегать
- Никогда не запускайте restic по живым файлам WiredTiger в /data/db — скопированные посреди чекпоинта, они несогласованы и часто невосстановимы.
- --oplog требует, чтобы сервер был членом replica set (хотя бы одноузлового); на standalone-mongod это no-op без гарантии point-in-time.
- При восстановлении --oplogReplay обязан сопровождать дампы с --oplog, иначе point-in-time-согласованность теряется.
Типичные проблемы резервирования MongoDB
- Симптом
- Дамп падает с «--oplog mode only supported on replica set members» (или похоже).
- Причина
- Ваш mongod работает standalone. --oplog нужен oplog для чтения, а его ведут только члены replica set — на standalone-сервере захватывать нечего.
- Решение
- Преобразуйте в одноузловой replica set: запустите mongod с --replSet rs0 и один раз выполните rs.initiate(). Тот же контейнер, те же данные, плюс гарантия point-in-time.
- Симптом
- mongodump падает с «Authentication failed», хотя compose задаёт MONGO_INITDB_ROOT_USERNAME.
- Причина
- Переменные MONGO_INITDB_* создают пользователя только при первой инициализации пустого тома /data/db. Если том уже существовал или учётные данные меняли позже, значения compose больше не отражают реальность.
- Решение
- Аутентифицируйтесь учётными данными, которые реально есть в базе (проверьте mongosh), или пересоздайте пользователя, затем выровняйте env compose.
- Симптом
- mongorestore в тестовый контейнер падает с ошибкой неподдерживаемой версии или неверного архива.
- Причина
- Архив от более нового сервера или mongodump, чем понимает цель — восстановление архива mongo:7 в mongo:5 не поддерживается.
- Решение
- Восстанавливайте в ту же мажорную версию (например mongo:7) и держите mongodump/mongorestore из одного релиза Database Tools. Апгрейд версий делает сервер после восстановления, а не mongorestore.
- Симптом
- Запуск резервного копирования падает с устаревшей блокировкой restic после сбоя или перезагрузки.
- Причина
- Предыдущая задача умерла посреди запуска и оставила репозиторий заблокированным.
- Решение
- Вручную делать ничего не нужно: следующий запуск обнаружит осиротевшую блокировку и автоматически выполнит restic unlock. Если запуски продолжают падать, посмотрите настоящую ошибку в панели живых логов.
Сделайте это в один клик с Dockstash
Dockstash выполняет ровно тот дамп, что выше, передаёт его restic вовне и автоматически проверяет восстановление тренировкой — без скриптов на поддержке.
Последнее обновление: July 2026
Часто задаваемые вопросы
Что на самом деле делает --oplog?
Он записывает элементы журнала операций, происходящие во время работы mongodump, и кладёт их в архив. При восстановлении --oplogReplay применяет их, чтобы дамп отражал один согласованный момент, а не размазню по окну дампа.
Нужен ли replica set для согласованных копий?
Для point-in-time-согласованности — да: --oplog работает только на члене replica set. Многие одноузловые развёртывания работают как replica set из одного члена именно ради этой гарантии.
Почему не копировать /data/db напрямую?
WiredTiger пишет чекпоинты непрерывно. Копия файлов посреди чекпоинта захватывает несогласованное состояние, которое часто не запускается. mongodump читает логический, восстановимый снимок.
Как восстановить в чистую базу?
mongorestore --archive --oplogReplay --drop удаляет существующие коллекции перед восстановлением, чтобы не смешивать старые и новые данные. Dockstash по умолчанию сначала восстанавливает в staging-цель.
Как часто резервировать MongoDB?
Ежедневно — практичный вариант по умолчанию; ежечасно — если потеря дня записей недопустима. На тарифе Free копии только вручную; Pro позволяет расписания вплоть до ежечасных, Business — любой cron. Сочетайте расписание с еженедельной тренировкой восстановления.
Где на самом деле живут резервные копии?
На вашем собственном VPS для хранения, как зашифрованные снимки restic, отправляемые по SSH. Dockstash никогда не держит ваши данные в чужом облаке — вы указываете машину под вашим контролем, а репозиторий зашифрован паролем, который есть только у вас.
Как узнать, что копия восстановима, без ручного восстановления?
Запланируйте тренировку восстановления. Dockstash восстанавливает последний снимок в изолированную рабочую область, сверяет каждый файл по байтам с источником и проверяет восстановленный дамп — затем ставит на проект значок «прошло/провалено». Еженедельная тренировка означает всегда свежее доказательство.