Резервное копирование MongoDB в S3 — простая инструкция

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

• Что такое лучшая стратегия резервного копирования?

• Настройка mongodump и S3

• Настройка Lifecycle в S3

Настройка резервных копий баз данных — ключевая задача администратора баз данных. Платформы Database-as-a-Service, такие как AWS RDS или MongoDB Atlas, могут делать это автоматически. Если вы управляете собственным сервером, резервирование придется настроить вручную.

Что такое лучшая стратегия резервного копирования?

Самое простое для поддержки решение — использовать управляемый сервис с автоматическими бекапами (RDS, DocumentDB, MongoDB Atlas). Эти сервисы умеют автоматически сохранять снапшоты и копировать их в S3 или собственное хранилище.

Если вы не хотите или не можете использовать облачный сервис, есть несколько подходов:

• Полностью управляемый сервис: самый простой путь — не беспокоиться о бэкапах. Подходит для большинства производственных систем.
• Mongo Cloud Manager: платный сервис (в исходном материале упоминается цена $40 в месяц за сервер) с автоматическими бэкапами и мониторингом. Хорош для шардов и реплик.
• Самописный подход: cron + mongodump или файловые снапшоты (LVM/ZFS/EC2/EBS snapshot).

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

Важно: оба метода допустимы. mongodump проще, файловые снапшоты более производительны на больших объёмах.

Важно: если у вас шард-кластер или крупная реплика, рассмотрите управляемые опции или инструменты, которые понимают репликацию и метаданные кластера.

Настройка mongodump и S3

Ниже — пример сценария для сервера. Предположения:

• AWS CLI установлен и настроен с IAM-учётной записью, имеющей доступ к бакету.
• Бакет создан заранее.

Скрипт сохраняется на сервере и запускается cron-ом.

export HOME=/home/ubuntu/

HOST=localhost

# DB name

DBNAME=database

# S3 bucket name

BUCKET=backups

# Linux user account

USER=ubuntu

# Current time

TIME=`/bin/date +%d-%m-%Y-%T`

# Backup directory

DEST=/home/$USER/tmp

# Tar file of backup directory

TAR=$DEST/../$TIME.tar

# Create backup dir (-p to avoid warning if already exists)

/bin/mkdir -p $DEST

# Log

echo "Backing up $HOST/$DBNAME to s3://$BUCKET/ on $TIME";

# Dump from mongodb host into backup directory

/usr/bin/mongodump -h $HOST -d $DBNAME -o $DEST

# Create tar of backup directory

/bin/tar cvf $TAR -C $DEST .

# Upload tar to s3

/usr/bin/aws s3 cp $TAR s3://$BUCKET/ --storage-class STANDARD_IA

# Remove tar file locally

/bin/rm -f $TAR

# Remove backup directory

/bin/rm -rf $DEST

# All done

echo "Backup available at https://s3.amazonaws.com/$BUCKET/$TIME.tar"

Пояснения к скрипту:

• export HOME — нужен для совместимости с cron, чтобы aws и другие инструменты могли найти конфигурацию.
• mongodump создаёт файлы по коллекциям в целевой папке.
• tar собирает отдельные файлы в один архив для удобной загрузки и хранения.
• aws s3 cp загружает архив в бакет; здесь используется класс хранения STANDARD_IA (Infrequent Access) для экономии.
• Скрипт удаляет временные файлы, чтобы не накапливать мусор локально.

Если скрипт работает локально, добавьте его в crontab:

crontab -e

И вставьте строку запуска (сначала можно тестировать запуск каждую минуту):

Настройте расписание на разумный интервал — один или два раза в день или чаще в зависимости от требований восстановления.

Советы по безопасности

• Не храните AWS-ключи в скриптах открытым текстом. Используйте IAM-роли (на EC2) или профиль AWS CLI с минимальными правами.
• Шифруйте трафик и используйте серверные политики доступа к бакету (Bucket Policy).
• Ограничьте доступ к скрипту и временным каталогам только нужным пользователям.

Настройка жизненного цикла (Lifecycle) в S3

Бекапы быстро занимают место. Оставлять их навсегда — неэффективно. S3 Lifecycle позволяет автоматически удалять старые архивы.

1. Откройте бакет в консоли S3, перейдите в раздел “Management” и нажмите “Add lifecycle rule”.

2. Примените правило ко всем объектам или по префиксу, задайте имя правила.

3. Перейдите к разделу Expiration и укажите количество дней, по истечении которых объекты удаляются.

4. Сохраните правило.

Теперь старые бекапы будут удаляться автоматически, и бакет не будет бесконтрольно расти.

Восстановление данных: краткая инструкция

1. Скачайте нужный архив из S3: aws s3 cp s3://BUCKET/TIME.tar ./
2. Распакуйте: tar xvf TIME.tar -C /tmp/restore
3. Используйте mongorestore: mongorestore -d target_db /tmp/restore/database

Проверьте целостность и индексы после восстановления.

Когда этот подход не подходит

• Очень большие базы данных (TB): mongodump медленный и создаёт большие архивы. Рассмотрите файловые снапшоты (LVM, ZFS) или потоковую репликацию.
• Критичные RTO/RPO: если требуется восстановление за минуты и минимальная потеря данных, используйте репликацию и Point-In-Time-restore (PITR), если доступно.
• Шардированные кластеры: mongodump требует аккуратности при согласовании локальных состояний; лучше управляемые инструменты или Cloud Manager.

Роли и ответственность

Роль: DBA

• Настроить регулярные бекапы и проверять их успешность.
• Тестировать восстановление хотя бы раз в квартал.

Роль: DevOps

• Обеспечить безопасное хранение ключей и автоматизацию (CI/CD, IAM роли).
• Настроить мониторинг успешности задач и алерты.

Роль: Разработчик

• Понимать требования к RTO и RPO для своего приложения.
• Участвовать в тестах восстановления в тестовой среде.

Шаблон плейбука для бекапа и восстановления

1. Настройка
   • Создать бакет S3 и IAM-политику.
   • Установить aws-cli и mongodump на хост.
   • Развернуть скрипт и дать права на исполнение.
   • Добавить в cron и протестировать.
2. Ежедневная проверка
   • Проверять логи cron и успешную загрузку в S3.
   • Убедиться, что Lifecycle работает.
3. Тест восстановления
   • Раз в квартал восстанавливать произвольную бэкап-версию на тестовый сервер.
4. Процедура при инциденте
   • Оповестить команду.
   • Выбрать последний валидный архив.
   • Выполнить восстановление в тестовой среде, затем в продакшн по согласованию.

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

• Архив успешно загружен в S3 и доступен через консоль.
• Lifecycle удаляет старые файлы по расписанию.
• Тестовое восстановление прошло без ошибок и проверка данных совпала с ожидаемым набором тестовых записей.

Риски и смягчения

• Потеря ключей доступа: использовать IAM роли и ключи с ограниченным сроком жизни.
• Коррупция архива: хранить контрольные суммы и проверять хеши после загрузки.
• Неправильные права бакета: аудит политик и тесты доступа из разных учётных записей.

Быстрые эвристики и модели принятия решений

• Если база < 200 GB и нет строгих SLA — mongodump + S3 подходит.
• Если нужно быстрое восстановление и база > TB — выбираем файловые снапшоты.
• Если кластер шарди или критичен RPO — рассмотреть Cloud Manager или управляемый сервис.

Мини-глоссарий

• mongodump — утилита MongoDB для экспортирования данных.
• mongorestore — утилита для восстановления дампа.
• Lifecycle — правила управления сроком жизни объектов в S3.
• STANDARD_IA — класс хранения S3 для редко запрашиваемых объектов.

Контрольный список перед переводом в продакшн

• IAM роль настроена без постоянных ключей в скрипте
• Регулярная проверка восстановления настроена
• Шифрование и политики доступа применены
• Lifecycle настроен и протестирован

Пример принятия решения (Mermaid)

flowchart TD
  A[Начало] --> B{База маленькая?}
  B -- Да --> C{Требуется RPO < 1ч?}
  C -- Да --> D[Использовать репликацию / PITR]
  C -- Нет --> E[Использовать mongodump + S3]
  B -- Нет --> F{Есть LVM/слишком большая?}
  F -- Да --> G[Использовать файловый снапшот]
  F -- Нет --> E
  D --> H[Тестировать восстановление]
  E --> H
  G --> H

Короткая сводка

• mongodump + tar + aws s3 cp — простой и переносимый способ сделать бекап MongoDB.
• Для автоматизации используйте cron, для хранения и ротации — S3 Lifecycle.
• Для больших/шардированных кластеров рассматривайте файловые снапшоты или управляемые сервисы.

Сводка действий: подготовьте IAM, сохраните скрипт, протестируйте cron, настройте Lifecycle, проводите регулярные тесты восстановления.