MongoDB
 sql >> база данни >  >> NoSQL >> MongoDB

Съвети за съхранение на резервни копия на MongoDB в облака

Когато става дума за архивиране и архивиране на данни, ИТ отделите са под натиск да спазват по-строги споразумения за ниво на обслужване, да предоставят повече персонализирани отчети и да се придържат към разширяващите се изисквания за съответствие, като същевременно продължават да управляват ежедневните задачи за архивиране и архивиране. Без съмнение сървърът на база данни съхранява част от най-ценната информация на вашето предприятие. Гарантирането на надеждни резервни копия на база данни за предотвратяване на загуба на данни в случай на авария или хардуерна повреда е критично поле за отметка.

Но как да го направите наистина DR, когато всичките ви данни са в един център за данни или дори центрове за данни, които са в близко геолокация? Освен това, независимо дали е 24x7 високо натоварен сървър или среда с нисък обем транзакции, ще имате нужда от правене на резервни копия безпроблемна процедура, без да нарушавате производителността на сървъра в производствена среда.

В този блог ще прегледаме архивирането на MongoDB в облака. Облакът промени индустрията за архивиране на данни. Поради достъпната си цена, по-малките фирми разполагат с външно решение, което архивира всичките им данни.

Ще ви покажем как да извършвате безопасно архивиране на MongoDB с помощта на mongo услуги, както и други методи, които можете да използвате, за да разширите опциите за възстановяване при аварийно възстановяване на базата данни.

Ако вашият сървър или дестинация за архивиране се намират в открита инфраструктура като публичен облак, доставчик на хостинг или е свързан чрез ненадеждна WAN мрежа, трябва да помислите за допълнителни действия във вашата политика за архивиране. Има няколко различни начина за извършване на архивиране на база данни за MongoDB и в зависимост от вида на архивирането, времето за възстановяване, размера и инфраструктурните опции ще варират. Тъй като много от решенията за облачно съхранение са просто съхранение с различни интерфейси на API, всяко решение за архивиране може да бъде изпълнено с малко скриптове. И така, какви са опциите, с които разполагаме, за да направим процеса гладък и сигурен?

Шифроване на резервно копие на MongoDB

Сигурността трябва да бъде в центъра на всяко действие на ИТ екипите. Винаги е добра идея да наложите криптиране, за да подобрите сигурността на архивните данни. Прост случай на използване за внедряване на криптиране е мястото, където искате да прехвърлите архива в хранилище за резервно копие извън сайта, разположено в публичния облак.

Когато създавате криптирано архивно копие, едно нещо, което трябва да имате предвид, е, че обикновено отнема повече време за възстановяване. Архивът трябва да бъде декриптиран преди всякакви дейности по възстановяване. При голям набор от данни това може да доведе до известно забавяне на RTO.

От друга страна, ако използвате частните ключове за криптиране, не забравяйте да съхранявате ключа на безопасно място. Ако частният ключ липсва, архивът ще бъде безполезен и невъзстановим. Ако ключът бъде откраднат, всички създадени резервни копия, които използват същия ключ, ще бъдат компрометирани, тъй като вече не са защитени. Можете да използвате популярните GnuPG или OpenSSL за генериране на частни или публични ключове.

За да извършите криптиране на MongoDBdump с помощта на GnuPG, генерирайте частен ключ и следвайте съответно съветника:

$ gpg --gen-key

Създайте обикновен резервно копие на MongoDBdump както обикновено:

$ mongodump –db db1 –gzip –archive=/tmp/db1.tar.gz
Шифровайте дъмп файла и премахнете по-стария обикновен архив:
$ gpg --encrypt -r ‘[email protected]’ db1.tar.gz

$ rm -f db1.tar.gz
GnuPG автоматично ще добави разширение .gpg към криптирания файл. За да декриптирате,

просто изпълнете командата gpg с флага --decrypt:

$ gpg --output db1.tar.gz --decrypt db1.tar.gz.gpg
За да създадете криптиран MongoDBdump с помощта на OpenSSL, трябва да генерирате частен ключ и публичен ключ:
OpenSSL req -x509 -nodes -newkey rsa:2048 -keyout dump.priv.pem -out dump.pub.pem

Този частен ключ (dump.priv.pem) трябва да се съхранява на сигурно място за бъдещо декриптиране. За Mongodump може да се създаде криптирано архивиране чрез прехвърляне на съдържанието към openssl, например

mongodump –db db1 –gzip –archive=/tmp/db1.tar.gz | openssl smime -encrypt -binary -text -aes256

-out database.sql.enc -outform DER dump.pub.pem
За да декриптирате, просто използвайте частния ключ (dump.priv.pem) заедно с флага -decrypt:

openssl smime -decrypt -in database.sql.enc -binary -inform

DEM -inkey dump.priv.pem -out db1.tar.gz

Компресия на резервно копие на MongoDB

В света на архивирането в облака на базата данни компресирането е един от най-добрите ви приятели. Това може не само да спести място за съхранение, но също така може значително да намали времето, необходимо за изтегляне/качване на данни.

В допълнение към архивирането, добавихме и поддръжка за компресиране с gzip. Това се разкрива чрез въвеждането на нова опция на командния ред „--gzip“ както в mongodump, така и в mongorestore. Компресията работи както за архивни копия, създадени с помощта на директорията, така и в режима на архивиране и намалява използването на дисково пространство.

Обикновено дъмпът на MongoDB може да има най-добри скорости на компресия, тъй като е плосък текстов файл. В зависимост от инструмента за компресиране и съотношението, компресиран MongoDBdump може да бъде до 6 пъти по-малък от оригиналния размер на архива. За да компресирате архива, можете да пренасочите изхода на MongoDBdump към инструмент за компресиране и да го пренасочите към целевия файл

Наличието на компресирано архивно копие може да ви спести до 50% от оригиналния размер на архива, в зависимост от набора от данни.

mongodump --db country --gzip --archive=country.archive

Ограничаване на пропускателната способност на мрежата

Чудесен вариант за архивиране в облак е ограничаването на честотната лента за поточно предаване на мрежата (Mb/s), когато правите архивиране. Можете да постигнете това с pv инструмент. Помощната програма pv идва с опция за модификатори на данни -L RATE, --rate-limit RATE, които ограничават трансфера до максимум RATE байтове в секунда. Примерът по-долу ще го ограничи до 2MB/s.

$ pv -q -L 2m

Прехвърляне на резервни копия на MongoDB в облака

Сега, когато резервното ви копие е компресирано и защитено (криптирано), то е готово за прехвърляне.

Google Cloud

Инструментът от командния ред gsutil се използва за управление, наблюдение и използване на вашите кофи за съхранение в Google Cloud Storage. Ако вече сте инсталирали gcloud util, вече имате инсталиран gsutil. В противен случай следвайте инструкциите за вашата Linux дистрибуция от тук.

За да инсталирате gcloud CLI, можете да следвате процедурата по-долу:

curl https://sdk.cloud.google.com | bash
Рестартирайте вашата обвивка:
exec -l $SHELL
Стартирайте gcloud init, за да инициализирате средата на gcloud:
gcloud init
С инсталиран и удостоверен инструмента на командния ред gsutil, създайте регионална кофа за съхранение с име MongoDB-backups-storage във вашия текущ проект.
gsutil mb -c regional -l europe-west1 gs://severalnines-storage/

Creating gs://MongoDB-backups-storage/

Amazon S3

Ако не използвате RDS за хостване на вашите бази данни, много вероятно е да правите свои собствени резервни копия. Платформата AWS на Amazon, S3 (Amazon Simple Storage Service) е услуга за съхранение на данни, която може да се използва за съхраняване на архивни копия на база данни или други критични за бизнеса файлове. Или това е екземпляр на Amazon EC2, или вашата локална среда, можете да използвате услугата, за да защитите данните си.

Докато резервните копия могат да се качват през уеб интерфейса, специалният интерфейс на командния ред s3 може да се използва за това от командния ред и чрез скриптове за автоматизиране на архивиране. Ако резервните копия трябва да се съхраняват много дълго време и времето за възстановяване не е проблем, резервните копия могат да бъдат прехвърлени към услугата Amazon Glacier, осигурявайки много по-евтино дългосрочно съхранение. Файловете (обектите на Amazon) се съхраняват логично в огромен плосък контейнер, наречен bucket. S3 представя REST интерфейс към своите вътрешни елементи. Можете да използвате този API, за да изпълнявате CRUD операции върху пакети и обекти, както и да променяте разрешенията и конфигурациите и на двете.

Основният метод за разпространение на AWS CLI в Linux, Windows и macOS е pip, мениджър на пакети за Python. Инструкции можете да намерите тук.

aws s3 cp severalnines.sql s3://severalnine-sbucket/MongoDB_backups
По подразбиране S3 осигурява единадесет 9s издръжливост на обекта. Това означава, че ако съхранявате 1 000 000 000 (1 милиард) обекта в него, можете да очаквате да загубите 1 обект средно на всеки 10 години. Начинът, по който S3 постига впечатляващ брой 9s, е чрез автоматично възпроизвеждане на обекта в множество зони за наличност, за което ще говорим в друга публикация. Amazon има регионални центрове за данни по целия свят.

Microsoft Azure Storage

Обществената облачна платформа на Microsoft, Azure, има опции за съхранение със своя интерфейс за контролна линия. Информация можете да намерите тук. С отворен код, кросплатформен Azure CLI предоставя набор от команди за работа с платформата Azure. Той предоставя голяма част от функционалността, наблюдавана в портала Azure, включително богат достъп до данни.

Инсталацията на Azure CLI е доста проста, можете да намерите инструкции тук. По-долу можете да намерите как да прехвърлите резервното си копие в хранилището на Microsoft.

az storage blob upload --container-name severalnines --file severalnines.gz.tar --name severalnines_backup

Хибридно хранилище за резервни копия на MongoDB

С нарастващата индустрия за публични и частни облачни хранилища имаме нова категория, наречена хибридно съхранение. Типичният подход е да съхранявате данни на локални дискови устройства за по-кратък период, докато облачното архивно съхранение ще се съхранява за по-дълго време. Много пъти изискването за по-дълго запазване на архива идва от правни задължения за различни индустрии (като телекомите, които трябва да съхраняват метаданни за връзката). Тази технология позволява файловете да се съхраняват локално, като промените се синхронизират автоматично с отдалечено в облака. Такъв подход идва от необходимостта от локално съхраняване на скорошни резервни копия за бързо възстановяване (по-ниско RTO), както и от целите за непрекъснатост на бизнеса.

Важният аспект на ефективното използване на ресурсите е да имате отделни резервни копия. Данните, които се съхраняват локално, на излишни дискови устройства, ще се съхраняват за по-кратък период, докато съхранението на облачно архивиране ще се съхранява за по-дълго време. Много пъти изискването за по-дълго запазване на резервно копие идва от правни задължения за различни индустрии (като телекомуникациите, които трябва да съхраняват метаданни за връзката).

Доставчиците на облак като Google Cloud Services, Microsoft Azure и Amazon S3 предлагат практически неограничено съхранение, намалявайки нуждите от локално пространство. Позволява ви да запазите архивните си файлове по-дълго, колкото искате и да нямате притеснения относно локалното дисково пространство.

Управление на архивиране на ClusterControl – хибридно съхранение

Когато планирате архивиране с ClusterControl, всеки от методите за архивиране може да се конфигурира с набор от опции за това как искате да се изпълни архивирането. Най-важното за хибридното облачно хранилище би било:

  • Намаляване на мрежата
  • Криптиране с вграденото управление на ключове
  • Компресия
  • Периодът на съхранение за локалните архиви
  • Периодът на задържане на облачните архиви

Разширени функции за архивиране на ClusterControl за облак, паралелна компресия, ограничение на честотната лента на мрежата, криптиране , и т.н. Вашата компания може да се възползва от мащабируемостта в облака и ценообразуването при разплащане за нарастващи нужди за съхранение. Можете да проектирате стратегия за архивиране, за да предоставите както локални копия в центъра за данни за незабавно възстановяване, така и безпроблемен шлюз към услуги за съхранение в облак от AWS, Google и Azure.

Разширени TLS и AES 256 -битови функции за криптиране и компресиране поддържат сигурни архиви, които заемат значително по-малко място в облака.


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Предоставя ли Mongoose достъп до предишната стойност на свойството в pre('save')?

  2. Колко по-бърз е Redis от mongoDB?

  3. Редът на полето в MongoDB и позицията на документа се променят след актуализация

  4. Паралелност в gopkg.in/mgo.v2 (Mongo, Go)

  5. MongoDB $sum Оператор на конвейер за агрегиране