Миграция MongoDB: бэкап и перенос сервера

Иллюстрация процесса миграции MongoDB

Быстрые ссылки

Using mongodump to Create a Backup
Restoring From Backup
Transfering The Entire Disk (Optional)

Когда использовать каждую стратегию

mongodump/mongorestore — просто и безопасно для небольших баз или при возможности кратковременного отключения записи.
Репликация и добавление ноды — лучший путь для миграции без простоев (hot-swap). Требует настройки реплики/кластера.
rsync (перенос диска) — удобно, если вы клонируете весь сервер или переносите VM/образ.

Важно: всегда планируйте окна обслуживания и выполняйте проверку целостности после переноса.

Использование mongodump для создания бэкапа

mongodump создаёт резервную копию базы и коллекций, которую потом можно восстановить. Процесс требует небольшого простоя, пока выполняется дамп и пока развертывается новый сервер.

Если простой недопустим, рассмотрите миграцию через добавление новой ноды в кластер и переключение трафика на неё — это минимизирует потерю записей. Это проще при использовании управляемого сервиса, например MongoDB Atlas.

Создайте каталог для бэкапов:

sudo mkdir /var/backups/mongobackups

Выполните mongodump, указав имя базы и место назначения:

sudo mongodump --db databasename --out /var/backups/mongobackups/backup

Можно дампить отдельную коллекцию через флаг –collection:

sudo mongodump --db databasename --collection collectionname --out /var/backups/mongobackups/backup

Совет: mongodump может выполняться на рабочей БД, но любые новые записи после начала дампа не попадут в резервную копию. Отключите запись или используйте режим читаемости только для приложения перед дампом.

Восстановление из бэкапа

Перед восстановлением перенесите архив бэкапа на новый сервер. Для больших бэкапов лучше использовать безопасный прямой перенос, например scp:

scp user@SRC_HOST:/var/backups/mongobackups/FILENAME user@DEST_HOST:~/FILENAME

Убедитесь, что MongoDB установлена на новом сервере. Для восстановления используйте mongorestore:

mongorestore

После успешного восстановления проверьте наличие коллекций и данных через mongo shell или клиент.

Важно: проверьте права доступа файлов, владельца процесса mongod и версии MongoDB — несовместимость версий может привести к ошибкам при восстановлении.

Смена привязки Elastic IP к другому серверу

Переключение трафика на новый сервер

После верификации данных нужно перенаправить трафик на новый хост. Варианты:

Обновить DNS-запись на новый IP (учтите TTL и время распространения).
Если провайдер поддерживает Elastic IP/Elastic IP association, сменить привязку IP к новому инстансу.
Использовать балансировщик нагрузки или proxy для минимального простоя.

Перенос всего диска (опционально)

Если вы переносите сервер целиком (например, апгрейд железа), можно скопировать корневую файловую систему. rsync подходит для этого: он синхронизирует файлы по SSH и поддерживает продолжение передачи.

Пример команды для отправки локального корня на удалённый хост (исключая временные и системные псевдофайловые системы):

sudo rsync -azAP / --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} username@remote_host:/

Флаги: -a — архивный режим (сохраняет права), -z — сжатие, -A —ACL, -P — прогресс + возможность возобновления.

Примечание: такой перенос потребует дополнительной настройки загрузчика, fstab и, возможно, переинициализации сетевых интерфейсов на новом хосте.

Безостановочная миграция через добавление ноды

Коротко: добавьте новый сервер в качестве реплики (secondary), дождитесь полной синхронизации, затем повысите его до primary или переключите записи. Это минимизирует потерю данных.

Шаги (вкратце):

Настройте mongod с репликацией на новом хосте.
Добавьте его в replSet через rs.add().
Дождитесь состояния SECONDARY и полного выполнения oplog.
Переключите приложение на запись в новый primary (или сделайте failover).

Преимущество: минимальные простои и почти нулевая потеря записей. Недостаток: сложнее настроить, требует понимания репликации и сетевых настроек.

Критерии приёмки

Все ожидаемые коллекции и документы присутствуют на новом сервере.
Запросы выборки/записи проходят базовые тесты (см. тесты ниже).
Права доступа и пользователи MongoDB настроены корректно.
Резервные копии хранятся отдельно от текущего окружения и доступны для восстановления.

Тесты и критерии приёмки

Доступность: запуск базовых CRUD-тестов (чтение/создание/обновление/удаление) на новом сервере.
Сравнение количества документов в ключевых коллекциях (old vs new).
Проверка индексов: список индексов совпадает.
Проверка логов на ошибки при запуске mongod.

Чек-листы по ролям

Администратор БД (DBA):

Подготовить дамп (mongodump) или настроить replSet.
Проверить совместимость версий MongoDB.
Верифицировать индексы и права.

Системный администратор / DevOps:

Настроить сервер, сеть, firewall и SSH.
Перенести файлы (scp/rsync) и настроить systemd/службы.
Обновить DNS/Elastic IP / балансировщик.

Разработчик приложения:

Обновить конфигурацию подключения (connection string).
Провести интеграционные тесты с новой базой.
Подготовить план отката на старый сервер.

Риски и способы смягчения

Риск	Влияние	Смягчение
Потеря записей при дампе	Высокое	Отключить запись или уведомить пользователей; использовать репликацию для нулевого даунтайма
Несовместимость версий MongoDB	Среднее/Высокое	Проверить версии и протестировать восстановление в staging
Ошибки прав/владельцев файлов	Среднее	Проверить владельца mongod и права после rsync/restore

Альтернативы и когда они не подходят

Использование файловой копии данных (копирование папки dbPath) быстрее, но требует остановки mongod и может быть рискованно при несоответствии версий.
Экспорт/импорт через mongoexport/mongoimport удобен для обмена данными в JSON/CSV, но теряет бинарные типы и индексную информацию.

Шаблон плана миграции (минимум)

Подготовка: проверить версии, создать бэкап конфигураций.
Создание бэкапа (mongodump) или настройка реплики.
Перенос файлов на новый сервер (scp/rsync) или репликация.
Восстановление/подключение и верификация данных.
Тесты интеграции и производительности.
Переключение трафика и мониторинг.
Роллбек-план при проблемах.

Пример сценариев тестирования (acceptance)

Событие: восстановление дампа прошло успешно. Критерии: количество записей в ключевой коллекции совпадает; индекс создан; приложения проходят smoke-тесты.
Событие: переключение IP/DNS. Критерии: 0 ошибок подключения у 95% пользователей в течение 10 минут после переключения.

Короткий чеклист по безопасности

Используйте SSH с ключами при переносе файлов.
Храните бэкапы в защищённом месте с ограниченным доступом.
После восстановления обновите пароли/ключи доступа, если переносили публично.

Короткое резюме

Миграция MongoDB возможна разными способами: дамп/восстановление (прост в реализации), добавление ноды в реплику (минимум простоев) или копирование диска (перенос сервера целиком). Выбор зависит от требований к доступности, размера данных и ресурсов команды. Всегда проверяйте совместимость версий, выполняйте тесты и имейте план отката.

Важно: перед любыми операциями сделайте полный план и тест в staging, чтобы минимизировать риски на продакшне.