Опции за архивиране в облак за MySQL и MariaDB бази данни

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

Защитата на данните остава предизвикателство за малкия и средния бизнес. Малките и средните предприятия предпочитат да архивират данните на компанията си, като използват директно свързано хранилище, като по-голямата част от фирмите планират да правят резервни копия извън сайта. Подходът за локално съхранение може да доведе до една от най-сериозните дилеми, пред които може да се изправи съвременната компания – загуба на данни в случай на бедствие.

Много фактори се обмислят, когато се преценява дали да се позволи прехвърлянето на критична за бизнеса база данни извън площадката и когато се избира подходящ доставчик за това. Традиционните методи като писане на лента и изпращане до отдалечено място могат да бъдат сложен процес, който изисква специален хардуер, адекватно обучен персонал и процедури, за да се гарантира, че архивните копия се създават редовно, защитават и че информацията, съдържаща се в тях, е проверена за целостта. Малките предприятия обикновено имат малки ИТ бюджети. Често те не могат да си позволят да имат вторичен център за данни, дори ако имат специален център за данни. Но въпреки това е важно да съхранявате копие на вашите архивни файлове извън сайта. Бедствия като ураган, наводнение, пожар или кражба могат да унищожат вашите сървъри и хранилище. Поддържането на архивирани данни в отделен център за данни гарантира, че данните са безопасни, без значение какво се случва във вашия основен център за данни. Облачното съхранение е чудесен начин за справяне с този проблем.
При подхода за архивиране в облак има редица фактори, които трябва да се вземат предвид. Някои от въпросите, които имате, са:

• Обезопасени ли са архивираните данни във външния център за данни?
• Безопасно ли е прехвърлянето към или от външния център за данни през обществената интернет мрежа?
• Има ли ефект върху RTO (Цел за време за възстановяване)?
• Процесът за архивиране и възстановяване достатъчно лесен ли е за нашия ИТ персонал?
• Има ли необходими промени в съществуващите процеси?
• Необходими ли са инструменти за архивиране на трети страни?
• Какви са допълнителните разходи по отношение на необходимия софтуер или трансфер на данни?
• Какви са разходите за съхранение?

Функции за архивиране при архивиране в облака

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

Шифроване

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

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

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

$ gpg --gen-key

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

$ mysqldump --routines --events --triggers --single-transaction db1 | gzip > 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

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

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

mysqldump --routines --events --triggers --single-transaction database | 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 database.sql

Percona XtraBackup може да се използва за криптиране или декриптиране на локални или стрийминг архиви с опция xbstream, за да добавите още един слой защита към архивите. Криптирането се извършва с библиотеката libgcrypt. Опцията --encrypt-key и опцията --encryptkey-file могат да се използват за определяне на ключа за криптиране. Ключовете за криптиране могат да се генерират с команди като

$ openssl rand -base64 24
$ bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1

След това тази стойност може да се използва като ключ за криптиране. Пример за командата innobackupex с помощта на --encrypt-key:

$ innobackupex --encrypt=AES256 --encrypt-key=”bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1” /storage/backups/encrypted

Резултатът от горната OpenSSL команда може също да бъде пренасочен към файл и може да се третира като ключов файл:

openssl rand -base64 24 > /etc/keys/pxb.key

Вместо това го използвайте с опцията --encrypt-key-file:

innobackupex --encrypt=AES256 --encrypt-key-file=/etc/keys/pxb.key /storage/backups/encrypted

За да декриптирате, просто използвайте опцията --decrypt с подходящ --encrypt-key или --encrypt-key-file:

$ innobackupex --decrypt=AES256 --encrypt-key=”bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1”
/storage/backups/encrypted/2018-11-18_11-10-09/

За повече информация относно криптирането на MySQL и MariaDB, моля, проверете друга публикация в нашия блог.

Компресия

В света на архивирането в облака на базата данни компресията е един от най-добрите ви приятели. Той не само може да спести място за съхранение, но също така може значително да намали времето, необходимо за изтегляне/качване на данни.
Налични са много инструменти за компресиране, а именно gzip, bzip2, zip, rar и 7z.
Обикновено mysqldump може да има най-добри скорости на компресия, тъй като е плосък текстов файл. В зависимост от инструмента за компресиране и съотношението, компресираният mysqldump може да бъде до 6 пъти по-малък от оригиналния размер на архива. За да компресирате архива, можете да пренасочите изхода на mysqldump към инструмент за компресиране и да го пренасочите към целевия файл. Можете също да пропуснете няколко неща като коментари, изявление за заключване на таблици (ако InnoDB), да пропуснете изчистване на GTID и задействания:

mysqldump --single-transaction --skip-comments --skip-triggers --skip-lock-tables --set-gtid-purged OFF --all-databases | gzip > /storage/backups/all-databases.sql.gz

С Percona Xtrabackup можете да използвате режима на поточно предаване (innobackupex), който изпраща архива до STDOUT в специален формат tar или xbstream, вместо да копира файлове в резервната директория. Наличието на компресирано архивно копие може да ви спести до 50% от оригиналния размер на архива, в зависимост от набора от данни. Добавете опцията --compress в командата за архивиране. Като използвате xbstream в поточно архивиране, можете да ускорите процеса на компресиране, като използвате опцията --compress-threads. Тази опция определя броя на нишките, създадени от xtrabackup за паралелно компресиране на данни. Стойността по подразбиране за тази опция е 1. За да използвате тази функция, добавете опцията към локално архивиране. Примерно архивиране с компресиране:

innobackupex --stream=xbstream --compress --compress-threads=4 > /storage/backups/backup.xbstream

Преди да приложите регистрационни файлове по време на подготвителния етап, компресираните файлове ще трябва да бъдат
декомпресирани с помощта на xbstream:
След това използвайте qpress, за да извлечете всеки файл, завършващ с .qp в съответната им директория, преди
изпълнение -- команда apply-log за подготовка на MySQL данните.

$ xbstream -x < /storage/backups/backup.xbstream

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

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

$ pv -q -L 2m

В примера по-долу можете да видите xtrabackup с паралелен gzip, криптиране

 /usr/bin/innobackupex --defaults-file=/etc/mysql/my.cnf --galera-info --parallel 4 --stream=xbstream --no-timestamp . | pv -q -L 2m | pigz -9 - | openssl enc -aes-256-cbc -pass file:/var/tmp/cmon-008688-19992-72450efc3b6e9e4f.tmp > /home/ubuntu/backups/BACKUP-3445/backup-full-2018-11-28_213540.xbstream.gz.aes256 ) 2>&1.

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

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

Облак на Google

Инструментът на командния ред 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, създайте регионална кофа за съхранение с име mysql-backups-storage във вашия текущ проект.

gsutil mb -c regional -l europe-west1 gs://severalnines-storage/
Creating gs://mysql-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/mysql_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.sql --name severalnines_backup

Хибридно хранилище за архивиране на MySQL и MariaDB

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

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

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

Заключение

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

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

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