Logical Backups
Logical backups dump data from databases into backup files, formatted as a BSON file. During the logical backup process, client APIs are used to get the data from the server. The data is encrypted, serialized, and written as either a “.bson,” “.json,” or “.csv” file, depending on the backup utility used. If you have enabled field level encryption, backing up data will ensure that the field remains encrypted.
MongoDB supplies two utilities to manage logical backups: Mongodump and Mongorestore.
The Mongodump command dumps a backup of the database into the “.bson” format, and this can be restored by providing the logical statements found in the dump file to the databases.
The Mongorestore command is used to restore the dump files created by Mongodump. Index creation happens after the data is restored.
Logical backups copy the data itself. They don’t copy any of the physical files relating to the data (like control files, log files, executables, etc.). They are typically used to archive databases, verify database structures, and move databases across different environments and operating systems.
If you have one server that contains a collection you need in another server, you could use a MongoDB logical backup to migrate the collection from the original server to the target server.
3: Восстановление и миграция MongoDB с помощью mongorestore
После восстановления БД MongoDB из резервной копии у вас будет точная копия данных MongoDB, созданная в определенное время (включая все индексы и типы). Это особенно полезно, если вы хотите перенести свои базы данных MongoDB на другую машину. Для восстановления MongoDB мы будем использовать команду mongorestore, которая работает с двоичными резервными копиями, созданными командой mongodump.
Давайте продолжим работу с нашей тестовой БД newdb и посмотрим, как восстановить ее из ранее созданной резервной копии. Сначала укажем имя базы данных с помощью аргумента –nsInclude (в нашем случае это newdb). Символ * нужен в команде для восстановления всех коллекций. Чтобы восстановить одну коллекцию, например restaurants, используйте вместо звездочки newdb.restaurants.
Затем, используя аргумент –drop, мы сбросим целевую БД, чтобы резервная копия была восстановлена в чистой базе данных. В качестве последнего аргумента мы укажем каталог последней резервной копии, который будет выглядеть примерно так: /var/backups/mongobackups/10-29-20/newdb/.
Если у вас есть резервная копия с меткой времени, вы можете восстановить ее с помощью этой команды:
Вы получите примерно такой вывод:
2020-10-29T19:25:45.825+0000 the --db and --collection args should only be used when restoring from a BSON file. Other uses are deprecated and will not exist in the future; use --nsInclude instead 2020-10-29T19:25:45.826+0000 building a list of collections to restore from /var/backups/mongobackups/10-29-20/newdb dir 2020-10-29T19:25:45.829+0000 reading metadata for newdb.restaurants from /var/backups/mongobackups/10-29-20/newdb/restaurants.metadata.json 2020-10-29T19:25:45.834+0000 restoring newdb.restaurants from /var/backups/mongobackups/10-29-20/newdb/restaurants.bson 2020-10-29T19:25:46.130+0000 no indexes to restore 2020-10-29T19:25:46.130+0000 finished restoring newdb.restaurants (25359 documents) 2020-10-29T19:25:46.130+0000 done
В приведенном выше примере мы восстанавливаем данные на том же сервере, на котором мы создали резервную копию. Если вы хотите перенести данные на другой сервер и использовать тот же метод, вам следует скопировать на новую машину ваш каталог резервных копий (в нашем мануале это /var/backups/mongobackups/10-29-20/newdb/).
Physical Backups
Physical backups are snapshots of the data files in MongoDB at a given point in time. The snapshots can be used to cleanly recover the database, as they include all the data found when the snapshot was created. Physical backups are critical when attempting to back up large databases quickly.
There are currently no provided, out-of-the-box solutions for creating physical backups with MongoDB. While you can create physical backups with LVM snapshots or block storage volume snapshots, it’s easier to use MongoDB Atlas. When using MongoDB Atlas, you can utilize any disk snapshot created by your cloud service provider. Alternatively, cloud backups can be made using either the MongoDB Cloud Manager or the Ops Manager.
Physical backups make copies of all the physical files that belong to a database, such as the data files, control files, and log files. The database files are saved onto a type of storage media, and they can then be used to restore a database system if there is damage to the system. You could use a physical backup snapshot alongside MongoDB Atlas to recover a lost or damaged database.
MongoDB Atlas Backup and Restore
MongoDB Atlas allows the user to create backups using the cloud backup system. MongoDB Cloud Backups are created using the native snapshot functionality of the cluster’s cloud service provider.
MongoDB Atlas supports cloud backups for clusters served on the following hosting platforms:
- Google Cloud Platform (GCP)
- Amazon Web Services (AWS)
- Microsoft Azure
The restore function in MongoDB Atlas lets the user restore to either a replica set or a sharded cluster, as long as the destination uses the same encryption provider as the snapshot cluster of origin. The target cluster must also be using either the same version of MongoDB or a newer version than the snapshot cluster. Legacy backups are supported but deprecated.
6: Тестовое восстановление данных
Любая стратегия резервного копирования должна содержать процедуру восстановления, которую нужно регулярно тестировать. Попробуйте восстановить данные из файла резервной копии, который вы загрузили в хранилище.
Сначала загрузите test_dump.gz из хранилища в домашний каталог на сервере MongoDB:
Если вы начали работу со свежего экземпляра MongoDB, у вас будет только БД test, которая, в свою очередь, стала единственной скопированной БД.
Для демонстрации теперь нужно удалить тестовую базу данных, чтобы вы могли выполнить чистое восстановление. Если мы не сделаете этого, процедура восстановления столкнется с оригинальными документами и не восстановит никаких данных – все они есть в оригиналах.
Подключитесь к MongoDB:
Выберите БД test и удалите ее с экземпляра MongoDB.
Вы увидите:
Теперь выйдите из оболочки mongo и выполните команду mongorestore:
В команде указано, что исходный файл резервной копии сжимается и хранится в формате архива (напомним, что мы использовали флаги –archive и –gzip при вызове mongodump).
Этот вывод значит, что БД восстановлена успешно.
Теперь убедитесь, что данные коллекции restaurants успешно восстановлены.
Откройте оболочку MongoDB и запросите коллекцию:
Вы увидите объект, сохраненный в первом разделе мануала:
Вы успешно скопировали и восстановили данные.
4: Восстановление снапшота MongoDB
Теперь попробуйте создать новый сервер, который будет восстановлен из только что созданного образа. В MongoDB будут доступны те данные, которые были доступны в ней в момент создания снапшота.
Вернитесь в меню снапшотов и найдите там ваш новый снапшот.
В меню можно создать новый сервер на основе данного образа.
Выберите образ и попробуйте подключиться к новому серверу, когда он будет создан.
Вы можете проверить работу MongoDB с помощью systemctl:
Это значит, что все хорошо и сервис MongoDB запущен правильно.
Если сервис MongoDB не запустился, сначала нужно удалить файл lock, а затем запустить сервис:
Убедитесь, что сервис MongoDB запущен правильно, используя команду systemctl status.
Как только MongoDB запустится, он начнет чистить данные и восстанавливать свое состояние до момента, когда был создан снапшот. Это может занять несколько минут, в течение этого времени оболочка mongo может быть недоступна.
Когда сервер станет доступным, вы можете войти с помощью команды mongo:
Вы увидите командную строку оболочки:
Вы успешно выполнили резервное копирование и восстановление базы данных MongoDB.
В качестве дополнительной меры предосторожности рекомендуется также проверить целостность коллекций
Шаг 2 — Экспорт информации из MongoDB
Как мы уже упоминали, при экспорте информации MongoDB вы можете получить удобный для чтения файлы с вашими данными. По умолчанию экспорт выполняется в формате json, но также вы можете использовать для экспорта формат csv (разделенные запятыми значения).
Чтобы экспортировать информацию из MongoDB, используйте команду . Это позволяет выполнять детализированный экспорт с указанием базы данных, коллекции, поля, или даже с использованием запроса для экспорта.
Простой пример работы команды — экспорт коллекции restaurants из базы данных , куда мы ее до этого импортировали. Это можно сделать следующим образом:
В команде выше мы используем для определения базы данных, для определения коллекции и для определения файла, куда будут сохранены данные.
Вывод успешной команды должен выглядеть вот так:
Этот вывод показывает, что было экспортировано 25359 документов, то есть, столько же документов, сколько мы импортировали.
В некоторых случаях, вам может быть нужно экспортировать только часть коллекции. Учитывая структуру и содержание файла restaurants json, давайте экспортируем все рестораны китайской кухни, расположенные в Бронксе. Если мы хотим получить эту информацию напрямую при подключении к MongoDB, нам нужно снова подключиться к базе данных:
Затем, используйте следующий запрос:
Результаты будут выведены на терминал:
Чтобы выйти из диалогового окна MongoDB, введите :
Если мы хотим экспортировать данные из командной строки sudo, а не во время подключения к базе данных, предыдущий запрос нужно сделать частью команды , указав его после аргумента :
Обратите внимание, что после двойных кавычек в тексте запроса идет обратная косая черта (). Точно так же нужно выделять и другие специальные символы в запросе
Если экспорт выполнен успешно, результат будет выглядеть вот так:
Выше показано, что мы экспортировали 323 записи, которые можно будет найти в заданном нами файле .
Используйте и для сканирования данных:
Используйте для прокрутки страниц данных:
Нажмите , чтобы выйти. Теперь вы можете импортировать и экспортировать базу данных MongoDB.
MongoDB Восстановление данных
MongoDB использовать mongorestore команду, чтобы восстановить резервную копию данных.
грамматика
mongorestore синтаксис команды сценария выглядит следующим образом:
>mongorestore -h dbhost -d dbname --directoryperdb dbdirectory
-h: Адрес сервера MongoDB, где
-d: Необходимо восстановить экземпляр базы данных, такие как: тест, конечно же, название может быть также резервное копирование и время не то же самое, например, test2
—directoryperdb: Резервное копирование данных о местоположении, например: C: \ Data \ свалка \ тест, почему должно быть больше испытание, а не резервное время сброса, читатель увидеть намек на это!
—drop: Время восстановления, сначала удалить текущие данные, а затем восстановить данные резервной копии
То есть, после возобновления, после добавления данных резервного копирования изменен, будут удалены, осторожность Oh!. Далее мы выполняем следующую команду:
Далее мы выполняем следующую команду:
>mongorestore
Выполните приведенную выше команду вывода результатов заключаются в следующем:
Предыдущая: MongoDB ломтик
Далее: MongoDB Мониторинг
Резервное копирование базы данных MongoDB
Важным аргументом команды mongodump является –db; он указывает имя БД, бэкап которой нужно создать. Аргумент –out задаёт каталог для хранения дампа. Давайте попробуем создать резервную копию БД newdb и поместить её в каталог /var/backups/mongobackups. В идеале каждая резервная копия должна храниться в каталоге с текущей датой (к примеру, /var/backups/mongobackups/04-20-16 – копия за 20 апреля 2016). Создайте каталог:
Теперь запустите команду для создания бэкапа:
В случае успешного копирования команда вернёт:
Обратите внимание на часть команды date +”%m-%d-%y”. Она автоматически устанавливает текущую дату
Это позволяет поместить копию в соответствующий каталог; эта функция особенно удобна при автоматическом резервном копировании.
Итак, у вас есть полная резервная копия БД newdb в каталоге /var/backups/mongobackups/01-20-16/newdb/. Эта копия позволяет полностью восстановить базу данных newdb, сохранив точность данных.
Как правило, резервные копии нужно создавать регулярно (например, на ежедневной основе); предпочтительно это делать во время низкой нагрузки на сервер. Для этого можно автоматизировать бэкап, поместив команду mongodump в cron. Откройте кронтаб:
Команда sudo crontab откроет для редактирования кронтаб пользователя root. Рекомендуется использовать именно этот кронтаб, поскольку таблицы других пользователей могут работать некорректно (например, демон cron может потребовать пароль). К примеру, чтобы демон создавал копию каждый день в 03:03 AM, нужно добавить в кронтаб:
В этой команде намеренно опущен аргумент –db, вследствие чего команда будет копировать все существующие базы данных.
Стоит отметить, что ежедневное резервное копирование относительно быстро потребляет дисковое пространство (в зависимости от объёма БД MongoDB). Потому рекомендуется регулярно удалять или сжимать старые копии. К примеру, чтобы удалить все копии старше 7 дней, можно использовать команду:
Эту команду можно также добавить в cron. Она должна запускаться незадолго до начала резервного копирования, например, в 03.01. Откройте кронтаб:
Вставьте в таблицу следующую строку:
3: Загрузка резервных данных в хранилище объектов
Чтобы загрузить архив в хранилище, нужен инструмент s3cmd.
Сначала проверьте конфигурацию s3cmd и попытайтесь получить доступ к хранилищу. В этом мануале мы будем использовать mongo-backup-demo в качестве тестового хранилища (но вы должны указать имя вашего хранилища):
Это значит, что соединение установлено успешно и s3cmd может перемещать объекты в хранилище.
Теперь давайте переместим созданный ранее архив:
Как только передача данных будет завершена, убедитесь, что файл был успешно перенесен в хранилище:
Вы должны увидеть архив резервной копии:
На этом этапе вы успешно создали резервную копию базы данных MongoDB и перенесли резервный архив в ваше хранилище.
Шаг 2 — Использование mongodump для резервного копирования базы данных MongoDB
Вначале поговорим о резервном копировании базы данных MongoDB.
Одним из самых важных аргументов команды является аргумент , указывающий имя базы данных, резервную копию которой вы хотите создать. Если вы не укажете имя базы данных, создаст резервные копии всех ваших баз данных. Второй важный аргумент — это аргумент , определяющий каталог, в котором будут сохранены данные. Давайте создадим резервную копию базы данных и сохраним ее в каталоге . В идеальной ситуации все наши резервные копии будут содержаться в каталоге с текущей датой .
Вначале создайте каталог :
Затем запустите команду :
Результат должен будет выглядеть следующим образом:
Обратите внимание, что в вышеуказанном пути каталога мы использовали формат , который автоматически получает текущую дату. Это позволяет нам размещать резервные копии в каталогах вида
Это особенно удобно для автоматизации резервного копирования.
Теперь у вас имеется полная резервная копия базы данных в каталоге . В этой резервной копии есть все необходимое для правильного восстановления и сохранения так называемой «корректности».
Как правило, резервное копирование выполняется регулярно, и обычно это делается в периоды наименьшей нагрузки на сервер. Вы можете задать команду как задачу планировщика (cron), чтобы она выполнялась регулярно, например, каждый день в 03:03.
Для этого откройте редактор crontab:
Обратите внимание, что при запуске вы будете редактировать кроны пользователя root. Рекомендуется сделать именно это, потому что если вы настроите кроны для своего пользователя, они могут выполняться неправильно, особенно если для вашего профиля sudo требуется проверка пароля
Вставьте в командную строку crontab следующую команду :
crontab
В приведенной выше команде мы целенаправленно опускаем аргумент , потому что обычно мы хотим создать резервные копии всех наших баз данных.
Если резервных копий будет слишком много, а базы данных MongoDB будут слишком большими, у вас быстро закончится место на диске. В связи с этим, также рекомендуется регулярно удалять старые резервные копии или сжимать их.
Например, вы можете использовать следующую команду bash для удаления всех резервных копий старше семи дней:
Аналогично предыдущей команде , вы можете добавить эту команду как задание cron. Его следует запускать непосредственно перед началом следующего резервного копирования, например, в 03:01. Для этого снова откройте crontab:
Вставьте следующую строку:
crontab
Сохраните и закройте файл.
Выполнение всех задач, описанных на этом шаге, обеспечит надлежащее решение резервного копирования для ваших баз данных MongoDB.
Шаг 1 — Импортирование информации в MongoDB
Чтобы узнать, как работает импорт информации в MongoDB, мы используем популярный образец базы данных MongoDB — базу о ресторанах. Эта база имеет формат json, и ее можно загрузить с помощью следующим образом:
После завершения загрузки в текущем каталоге должен быть файл (размер 12 Мбайт). Импортируем данные из этого файла в новую базу данных и в коллекцию .
Используйте команду следующим образом:
Результат будет выглядеть вот так:
Как показывает приведенная выше команда, были импортированы 25359 документов. Поскольку у нас не было базы данных с именем , MongoDB создала ее автоматически.
Давайте проверим импорт.
Подключитесь к только что созданной базе данных :
Вы подключились к экземпляру базы данных
Обратите внимание, что ваша командная строка изменилась. Это означает, что вы подключены к базе данных
Подсчитайте число документов в коллекции restaraunts с помощью команды:
Будет выведен результат , т. е. количество импортированных документов. Для еще более эффективной проверки вы можете выбрать первый документ из коллекции restaraunts следующим образом:
Результат будет выглядеть вот так:
Такая детальная проверка может выявить проблемы с содержанием документа, кодировкой и т. д. Формат json использует кодировку , и ваши операции экспорта и импорта также должны использовать эту кодировку. Это необходимо помнить при редактировании файлов json вручную. В противном случае MongoDB автоматически сделает это за вас.
Чтобы выйти из командной строки MongoDB, введите команду :
Вы вернетесь в обычную командную строку как пользователь без привилегий root.
При возникновении проблемы невозможности скопировать базу данных с помощью инструментов визуализации MongoDB (таких как Robo 3T), как сделать резервную копию и восстановить базу данных?
Когда мы хотим скопировать все данные из определенной среды (например, тестовой) в другую среду (например, локальную), если на компьютере установлен только бесплатный инструмент визуализации MongoDB, например Robo 3T, потому что Похоже, что Robo 3T не поддерживает копирование базы данных, поэтому сейчас нам следует подумать о другом способе. Давайте рассмотрим полную демонстрацию того, как сделать резервную копию и восстановить базу данных в этой ситуации. Если у вас есть лучший метод, вы можете оставить сообщение в области сообщений. Я дополню и улучшу его позже.
метод первый:
Существует два основных типа резервного копирования и восстановления базы данных mongodb, один из которыхПротив библиотекиMongodump и mongorestore, один из нихДля столов в библиотекеМонгоэкспорт и монгоимпорт.Примечания: обязательно обратите вниманиеКоманды операционной библиотеки и операционной таблицы разные., Он потерпит неудачу, если вы сделаете ошибку. Общий формат команд базы данных резервного копирования mongodump:
Общий формат команд базы данных резервного копирования mongodump:
среди них,
Здесь я использую командную строку git для резервного копирования базы данных, пример следующий.
Метод второй:
Если вы хотите скопировать базу данных в тестовую среду, но протокол, которому следует база данных, не является HTTP (например, SSH), то указанный выше метод не будет работать в настоящее время, в этом случаеСначала войдите на тестовый сервер, выполните mongodump в контейнере докеров mongodb на сервере, а затем скопируйте файл на локальный. Конкретные шаги заключаются в следующем:1. Войдите на тестовый сервер (выполните команду ssh для удаленного подключения к тест-серверу) Откройте любой инструмент оболочки, я использую здесь оболочку bash, введите следующую команду:
Среди них замените ключевой файл на свой собственный путь к файлу закрытого ключа. Файл закрытого ключа можно найти, просмотрев конфигурацию базы данных, например, открыв Robo 3T и просмотрев конфигурацию.2. Выполните следующую команду, войдите в контейнер докеров и найдите контейнер докеров с именем mongodb на тестовом сервере (чтобы найти точное имя контейнера mongodb, мой называется mongodb, и вы можете настроить его в соответствии с вашей реальной ситуацией)
Затем выполните следующую команду, чтобы войти в контейнер mongodb (все команды, выполненные впоследствии, будут выполняться в контейнере mongodb, что эквивалентно удаленному подключению к виртуальной машине)
3. Выполните команду mongodump в контейнере mongodb, чтобы экспортировать данные в каталог тома, к которому можно получить доступ извне.Команда mongodump принимает — archive = / dump.data для упаковки результатов экспорта в один файл dump.data, который удобно передавать на локальный. /Dump.data здесь означает файл dump.data в корневом каталоге контейнера mongodb
После выполнения команды вернитесь в корневой каталог контейнера mongodb и выполните команду просмотра файла ls. Если в списке файлов есть dump.data, экспорт успешен.4. Используйте такие инструменты, как ssh или FileZila, чтобы скопировать файлы на тестовом сервере с сервера на локальный. Сначала выйдите из контейнера, выполните команду exit напрямую, выйдите из оболочки, а затем выйдите из контейнера.
Теперь среда командной строки снова переключается на тестовый сервер, выполните docker cp, чтобы скопировать файлы из контейнера на хост-машину (то есть на тестовый сервер).Пример выглядит следующим образом: Скопируйте dump.data из корневого каталога контейнера mongodb в корневой каталог хоста и сохраните то же имя файла
Вернитесь в корневой каталог тестового сервера (введите команду cd /), введите команду просмотра файла ls, и вы увидите только что скопированный файл. Затем выполните команду выхода, чтобы выйти из тестового сервера.
5. Используйте команду scp, чтобы получить скопированные файлы с тестового сервера.
Затем проверьте свой локальный путь и получите файл, который хотите получить5. Выполните команду mongodbrestore локально, чтобы восстановить базу данных. восстановить файлы, зарезервированные локально, в библиотеку mongodb, — archive == xxx — это указанный входной файл
Значит, в местной библиотеке mongodb есть данные!
5: Проверка целостности данных
Перед запуском данных этой резервной копии в производство полезно проверить восстановленные коллекции на наличие недействительных объектов BSON.
Примечание: Команда validate медленно работает в очень больших коллекциях. Кроме того, все операции чтения и записи в коллекции будут заблокированы до тех пор, пока команда validate не закончит работу.
В этом примере используется тестовая коллекция restaurants, в которой нужно запустить команду validate.
Из оболочки mongo запустите команду validate:
Вы должны увидеть такой вывод:
Если вы видите valid: true, значит, все аспекты коллекции действительны, и вы можете спокойно использовать данные из этой коллекции в производстве.
5: Планирование ежедневного бэкапа с помощью cron
Чтобы запланировать запуск сценария резервного копирования ночью, можно использовать cron, утилиту планирования заданий, встроенную в Unix-подобные операционные системы.
Сначала создайте каталог для хранения логов сценария резервного копирования. Затем добавьте сценарий в файл конфигурации crontab (cron), чтобы демон мог запускать его каждую ночь. Поскольку cron поддерживает любую частоту запуска задач, вы можете дополнительно спланировать еженедельное или ежемесячное резервное копирование.
Создайте каталог для хранения логов сценария резервного копирования. Эти логи позволят вам периодически проверять сценарий, чтобы убедиться, что все в порядке; также их можно использовать для отладки.
Создайте подкаталог mongo_backup в /var/log:
Затем дайте пользователю Unix право на запись в нем. В данном случае пользователь условно называется 8host (укажите имя своего пользователя).
Теперь этот пользователь имеет право на запись в /var/log/mongo_backup. Поскольку cronjob запускается от имени 8host, он теперь может писать в логах.
Создание cronjob
Чтобы запланировать сценарий, нужно отредактировать crontab. На каждого пользователя выделяется по одному crontab-у, также есть общий crontab в /etc/crontab. Запланировать сценарий нужно в crontab-е вашего текущего пользователя (здесь это 8host). В некоторых ситуациях это можно сделать и в общесистемном crontab-е.
Откройте crontab:
Вам будет предложено выбрать текстовый редактор:
Выберите редактор, указав его порядковый номер. Затем добавьте в файл после закомментированных строк следующую строку:
Обязательно добавьте новую строку в конце crontab. Сохраните и закройте файл.
Вы увидите следующий результат:
Сценарий резервного копирования будет запускаться в 2 часа ночи. stdout и stderr (потоки выходных данных и ошибок) будут переданы и добавлены в лог mongo_backup.log в каталоге, который вы создали ранее.
Вы можете изменить 0 2 * * * (2 часа ночи в синтаксисе cron) и указать другое время и частоту резервного копирования. Чтобы узнать больше о cron и его синтаксисе, ознакомьтесь с руководством Автоматизация задач с помощью Cron.
2: Резервное копирование MongoDB с помощью mongodump
Сначала мы рассмотрим резервное копирование базы данных MongoDB.
Важным аргументом команды mongodump является –db, он указывает имя БД, резервную копию которой вы хотите создать. Если вы не укажете имя базы данных, mongodump создаст резервную копию всех ваших баз данных.
Второй важный аргумент – это –out, он определяет каталог, в который будут выгружены данные. Для примера давайте создадим резервную копию БД newdb и сохраним ее в каталоге /var/backups/mongobackups. В идеале каждая из наших резервных копий появится в каталоге с текущей датой (в формате /var/backups/mongobackups/10-29-20).
Сначала создайте необходимый каталог /var/backups/mongobackups:
А теперь запустите команду mongodump:
Вы увидите такой вывод:
2020-10-29T19:22:36.886+0000 writing newdb.restaurants to 2020-10-29T19:22:36.969+0000 done dumping newdb.restaurants (25359 documents)
Обратите внимание, что в указанном выше пути к каталогу мы использовали date +”%m-%d-%y”, что автоматически установит текущую дату. Это позволит нам создавать резервные копии внутри каталога, например, /var/backups/10-29-20/
Это особенно удобно, когда мы автоматизируем резервное копирование.
На этом этапе у вас есть полная резервная копия базы данных newdb в каталоге /var/backups/mongobackups/10-29-20/newdb/. В этой резервной копии есть все, чтобы правильно восстановить newdb и сохранить точность и целостность данных.
Как правило, резервные копии должны создаваться регулярно, желательно тогда, когда сервер наименее загружен. Чтобы сделать это, можно установить команду mongodump как задание cron, чтобы она выполнялась в определенное время, например, каждый день в 03:03.
Для этого откройте crontab, редактор cron:
Обратите внимание, что при запуске sudo crontab вы будете редактировать задания cron для пользователя root. Рекомендуется делать именно так, потому что если вы установите crons для другого пользователя, задачи могут работать некорректно (особенно если ваш профиль sudo требует проверки пароля)
В командную строку crontab введите следующую команду mongodump:
В приведенной выше команде мы намеренно опускаем аргумент –db, потому что резервное копирование обычно требуется всем базам данных.
В зависимости от размеров вашей БД MongoDB, рано или поздно у вас закончится дисковое пространство – накопится много резервных копий. Вот потому также рекомендуется регулярно удалять или сжимать старые копии.
Например, чтобы удалить все резервные копии старше семи дней, вы можете использовать следующую команду bash:
Как и предыдущую команду mongodump, вы можете добавить ее как задачу cron. Она должна запускаться непосредственно перед началом следующего резервного копирования, например, в 03:01. Снова откройте crontab:
После этого вставьте следующую строку:
Сохраните и закройте файл.
Все эти задачи обеспечат правильное выполнение резервного копирования ваших баз данных MongoDB.
How to Back Up and Restore a MongoDB Database
Now, we’ll take a look at how to create a MongoDB backup database and restore that database. We’ll do this with both MongoDB Atlas and with the Mongodump and Mongorestore utilities.
Using MongoDB Atlas
When using MongoDB Atlas, the snapshots are created by your cloud service provider, so be sure to refer to the corresponding documentation to configure your snapshots. Once a snapshot has been taken, you can use the option in MongoDB Atlas.
After ensuring that the Atlas cluster of choice can’t receive client requests or choosing to restore to a new Atlas cluster, simply navigate to the “Clusters” view in MongoDB Atlas. Afterwards, select “Backup,” choose a snapshot to restore, and then follow the prompts to restore your cluster.
Предварительные требования
Перед выполнением этого учебного модуля необходимо следующее:
- Один дроплет Ubuntu 20.04, настроенный в соответствии с руководством по начальной настройке сервера Ubuntu 20.04, в том числе пользователь без привилегий root с привилегиями sudo и брандмауэр.
- СУБД MongoDB, установленная и настроенная согласно указаниям статьи Установка MongoDB в Ubuntu 20.04.
- Пример базы данных MongoDB, импортированной в соответствии с инструкциями учебного модуля Импорт и экспорт базы данных MongoDB.
Если не указано иное, все команды в этом учебном модуле, для которых требуются привилегии root, должны выполняться пользователем без привилегий root с привилегиями sudo.
3: Создание снапшота
Чтобы скопировать БД, вам нужна функция создания снапшота от вашего хостинг-провайдера. Эта функция позволяет создавать образы серверов на текущий момент времени. Потом образ можно восстановить на новом сервере.
Учитывая, что вы используете MongoDB 3.2+ (с включенным WiredTiger и журналированием), вам не нужно приостанавливать запись в файловую систему на время создания снапшота. Как только вы восстановите образ и запустите базу данных, MongoDB восстановит себя с контрольной точки, а затем воспроизведет операции из журналов, пока не достигнет момента создания снапшота. Чтобы узнать больше о журналировании, обратитесь к руководству MongoDB.
Итак, войдите в свой аккаунт на хостинге и выберите функцию снапшотов в меню.
Примечание: Хотя обычно перед созданием снапшотов рекомендуется остановить сервер, в среде производства это не всегда возможно. Журналирование в MongoDB обеспечивает согласованные и достоверные снапшоты, даже если во время их создание БД и сервер не были остановлены.
Дайте вашему снапшоту описательное имя и запустите копирование.
После создания снапшота вы сможете развернуть новый сервер с помощью полученного образа или восстановить текущий сервер в состояние, зафиксированное в снапшоте.
Теперь можно выполнить восстановление, чтобы проверить процедуру резервного копирования.
