Резервные копии кластера MongoDB — копии баз данных, которые хранятся в выделенном бакете и защищаются шифрованием. Базы данных можно восстановить в случае их потери или повреждения.

Виды резервного копирования кластера MongoDB:

  • PITR (Point-in-Time-Recovery) — базовая резервная копия, которая автоматически создаётся в момент создания кластера MongoDB. Кластер из базовой копии можно восстановить на любой момент времени — в интервале от создания базовой резервной копии до последней записи в лог-файл;
  • ручноеполная резервная копия всех баз данных кластера, создаётся вручную;
  • автоматическое — полная резервная копия всех баз данных кластера. Автоматическое создание резервных копий включается при создании кластера с помощью переключателя Включить автоматическое резервное копирование. Ежедневно в указанное время с ноды в кластере Standalone или с ноды-лидера в кластере Replica Set создаётся полная копия всех баз данных. По истечении указанного количества дней резервная копия удаляется автоматически в 00:00:00 UTC.

Все резервные копии отображаются на портале на вкладке Резервные копии.

Создание резервной копии кластера MongoDB вручную

Чтобы создать резервную копию кластера MongoDB вручную:

  1. В главном меню портала перейдите в раздел Ресурсы  Базы данных → Managed Service for MongoDB.
  2. В строке кластера, резервную копию которого нужно создать, нажмите на кнопку .
  3. Перейдите на вкладку Резервные копии и нажмите на кнопку Создать бекап.

Созданная резервная копия отображается на портале

Тип резервного копирования logical — логическая резервная копия кластера, при которой копируются только данные, находящиеся в файлах, а не сами файлы.

Восстановление кластера MongoDB из резервной копии

Существует два способа восстановления кластера MongoDB из резервной копии:

  • восстановление из резервной копии — создаётся новый кластер из ранее созданной резервной копии (базовой, ручной или автоматической) баз данных;
  • восстановление с помощью PITR — кластер можно восстановить на любой момент времени — в интервале от создания базовой резервной копии до момента последней записи в лог-файл. Например, если создание резервной копии завершилось 10.12.2023 в 12:00:00 UTC, а последняя запись в лог-файл сохранена 12.12.2023 в 18:50:00 UTC, то кластер можно восстановить на любой момент времени в промежутке с 10.12.2023 12:00:01 UTC до 12.12.2023 18:50:00 UTC включительно.

Чтобы восстановить кластер MongoDB из резервной копии:

  1. В главном меню портала перейдите в раздел Ресурсы  Базы данных → Managed Service for MongoDB.
  2. Нажмите на кнопку Заказать.
  3. Активируйте переключатель Создать кластер из резервной копии.
  4. Выберите способ Восстановление из резервной копии или Восстановление c помощью PITR.
  5. Заполните поля:

  • Выберите кластер * — кластер, который нужно восстановить из резервной копии;
  • если выбрано Восстановление из резервной копии, то

    1. В главном меню портала перейдите в раздел Ресурсы → Базы данных → Managed Service for MongoDB.
    2. В строке кластера, в котором нужно посмотреть имя резервной копии, нажмите на кнопку .
    3. Перейдите на вкладку Резервные копии:

  • если выбрано Восстановление c помощью PITR, то

    1. В главном меню портала перейдите в раздел Ресурсы → Базы данных → Managed Service for MongoDB.
    2. В строке кластера, который нужно восстановить из резервной копии, нажмите на кнопку .
    3. На вкладке Резервные копии выберите раздел PITR:
  • Название кластера * — уникальное имя кластера в рамках проекта. Значение по умолчанию — mongodb-vm-<номер>, например, mongodb-vm-0001;

  • Описание кластера — описание кластера, заполняется при необходимости;
  • Версия MongoDB — доступная версия MongoDB. Выбранная версия MongoDB должна совпадать с версией, используемой в восстанавливаемом кластере;
  • Кол-во нод в кластере * — нечётное количество нод в кластере от 1 до 29. Количество нод в новом кластере должно совпадать с количеством нод в восстанавливаемом кластере;
  • Включить Публичный IP-адрес  — активируйте переключатель, если к кластеру нужен доступ из сети Интернет. К каждой ноде в кластере будет привязан свой публичный IP-адрес, который отображается на вкладке Ноды.

  • Регион — регион расположения кластера;
  • Зона доступности — зона доступности, в которой будет находиться кластер;
  • Подсеть — подсеть, к которой будет подключен кластер.

Вычислительные ресурсы: 

  • Общие — для публичного облака;
  • Персональные — для частного облака.

Семейство — семейство процессоров:

  • general-purpose — процессоры с частотой 2.2 GHz с конфигурациями b2, с частотой 2.8 GHz с конфигурациями b5, с частотой 3.0 GHz с конфигурациями b3 и процессоры с частотой 4.05 GHz с конфигурациями b4;
  • Advanced — процессоры с частотой 3.0 GHz с конфигурациями a1 и процессоры с частотой 2.8 GHz с конфигурациями a5; 
  • Memory-optimized — процессоры с частотой 2.9 GHz с конфигурациями m1.
    Подробнее см. раздел Конфигурации сервера.

Серия — серия процессоров:

  • Intel Cascade Lake 2.2 GHz;
  • Intel Ice lake 2.8 GHz;
  • Intel Cooper Lake 2.9 GHz;
  • Intel Cascade Lake 3.0 GHz;
  • AMD EPYC 9004 series 4.05 GHz.

Конфигурация  количество процессоров (CPU) и объём оперативной памяти (RAM). Подробнее см. раздел Конфигурации сервера.

Объем хранилища:

  • Размер диска, Гб *  размер выделенной памяти на каждой ноде кластера, от 10 Гб до 2048 Гб. Размер диска нового кластера должен быть не меньше, чем у восстанавливаемого;
  • Тип * — тип диска:

  • Тип * — тип диска:
    • Light - IOPS Read: 500 IOPS Write: 300;
    • Basic - IOPS Read: 3000 IOPS Write: 1000;
    • Average cluster 1 - IOPS Read: 10000 IOPS Write: 3000;
    • Average cluster 2 - IOPS Read: 10000 IOPS Write: 3000;
    • Average cluster 3 - IOPS Read: 10000 IOPS Write: 3000;
    • High cluster 1 - IOPS Read: 15000 IOPS Write: 5000;
    • High cluster 2 - IOPS Read: 15000 IOPS Write: 5000;
    • High cluster 3 - IOPS Read: 15000 IOPS Write: 5000.

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

      Примечания

      1. Тип дисков Average cluster и High cluster рекомендуется использовать для серверов, предназначенных для построения кластера на независимых друг от друга дисках. Например, при организации систем типа Primary-Secondary (Master-Slave).
      2. Для оптимальной работы и надёжности хранения данных диски Light и Basic проходят ежедневную проверку и исправление ошибок. В процессе этих проверок могут увеличиваться задержки (latency). Если вам нужна стабильно высокая производительность дисков, выбирайте High cluster. Подробнее см. раздел Задержка и производительность дисков.

При необходимости активируйте переключатель Включить автоматическое резервное копирование всех баз данных кластера и заполните поля: 

  • Время автоматического резервного копирования UTC *  время в формате hh:mm:ss. Значение по умолчанию 00:00:00. Ежедневно в указанное время с ноды в кластере Standalone или с ноды-лидера в кластере Replica Set создаётся полная копия всех баз данных, которая отображается на вкладке Резервные копии;
  • Кол-во дней хранения автоматических резервных копий *  от 1 до 7. По истечении указанного количества дней резервная копия удаляется автоматически в 00:00:00 UTC.

6. Нажмите на кнопку Заказать.

В результате создастся новый кластер из резервной копии, который отобразится на портале в разделе Ресурсы Базы данных → Managed Service for MongoDB.

Удаление резервной копии

Нельзя удалить базовую резервную копию (PITR), которая автоматически создаётся в момент создания кластера MongoDB. Остальные резервные копии можно удалять.

Чтобы удалить резервную копию:

  1. В главном меню портала перейдите в раздел Ресурсы  Базы данных → Managed Service for MongoDB.
  2. В строке кластера, резервную копию которого нужно удалить, нажмите на кнопку .
  3. Перейдите на вкладку Резервные копии и в строке с резервной копией, которую нужно удалить, нажмите на кнопку .
  4. Нажмите на кнопку Да.

Все резервные копии удаляются автоматически после удаления кластера.

  • No labels