ИТ Блог. Работа с базой данных (MySQL, CouchDB, MariaDB, MongoDB)
Основная задача резервного копирования ваших данных – это, конечно же, возможность отката и доступа к вашим архивам в случае отказа оборудования. Чтобы сегодня вести бизнес, вам нужно знать, что в случае бедствия ваши данные будут защищены и доступны. Вам нужно будет хранить резервные копии за пределами площадки, если ваш центр обработки данных горит.
Защита данных остается проблемой для предприятий малого и среднего бизнеса. Компании малого и среднего бизнеса предпочитают архивировать данные своей компании, используя хранилище с прямым подключением, причем большинство фирм планируют делать резервные копии вне офиса. Локальный подход к хранению данных может привести к одной из самых серьезных проблем, с которыми может столкнуться современная компания – потеря данных в случае бедствия.
Многие факторы приходят к обсуждению, если судить о том, следует ли передавать бизнес-критическую базу данных за пределы страны и выбирать подходящего поставщика для этого. Традиционные методы, такие как запись на магнитную ленту и отправку в удаленное местоположение, могут быть сложным процессом, требующим специального оборудования, надлежащим образом обученного персонала и процедур для обеспечения регулярного создания и защиты резервных копий и обеспечения целостности информации, содержащейся в них. Малые предприятия обычно имеют небольшие ИТ-бюджеты. Часто они не могут позволить себе иметь вторичный центр обработки данных, даже если у них есть выделенный центр обработки данных. Но, тем не менее, по-прежнему важно сохранить копию резервных файлов за пределами площадки. Такие катастрофы, как ураган, наводнение, пожар или кража, могут уничтожать ваши серверы и хранилища. Сохранение резервных копий данных в отдельном центре обработки данных гарантирует, что данные будут безопасными, независимо от того, что происходит в вашем основном центре обработки данных. Облачное хранилище – отличный способ решить эту проблему.
При использовании подхода резервного копирования облака необходимо учитывать несколько факторов. Некоторые из ваших вопросов:
Если ваш сервер 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 ‘admin@email.com’ 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:
$ 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
Наличие сжатой резервной копии может сэкономить до 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 в секунду. Ниже пример ограничит его до2 МБ/с.
$ 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.
Теперь, когда ваша резервная копия сжата и зашифрована, она готова к передаче.
Инструмент командной строки gsutil используется для управления, мониторинга и использования ваших хранилищ в облачном хранилище Google. Если вы уже установили утилиту gcloud, у вас уже установлен gsutil. В противном случае следуйте инструкциям для вашего дистрибутива Linux.
Чтобы установить CLI gcloud, вы можете выполнить следующую процедуру:
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/
Если вы не используете 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
По умолчанию S3 обеспечивает долговечность объекта в течение 9 лет. Это означает, что если вы храните в нем 1.000.000.000 (1 миллиард) объектов, вы можете ожидать потерять 1 объект каждые 10 лет в среднем. То, как S3 достигает впечатляющего числа 9s, автоматически реплицирует объект в нескольких зонах доступности, о которых мы поговорим в другом сообщении. Amazon имеет региональные центры обработки данных по всему миру.
Общая облачная платформа Microsoft, Azure, имеет опции хранения с интерфейсом линии управления. Информацию можно найти здесь . Открытый межплатформенный Azure CLI обеспечивает набор команд для работы с платформой Azure. Это дает большую часть функциональности, видимой на портале Azure, включая богатый доступ к данным.
Установка Azure CLI довольно проста, вы можете найти инструкции здесь . Ниже вы можете найти, как перенести резервную копию на хранилище Microsoft.
az storage blob upload --container-name severalnines --fileТэги: , MariaDB, MySQL, резервное копирование Категории: Базы данных
