Percona внесла большой вклад в мир программного обеспечения с открытым исходным кодом. Один из самых популярных продуктов Percona — это программное обеспечение для резервного копирования MySQL и MongoDB. Подобное программное обеспечение играет жизненно важную роль для резервного копирования и разработки планов аварийного восстановления.

Важным моментом является место хранения резервных копий. Здесь важна не только возможность восстановления из резервной копии, но и безопасность хранения, чтобы у посторонних лиц не было к ним доступа.

Обычно резервные копии хранятся в нескольких местах, в том числе в облаках. Облачное хранилище обладает преимуществами благодаря экономической эффективности, безопасности и высокой доступности.

Теперь давайте подробнее поговорим о хранении резервных копий в облаке.

Безопасность на первом месте

Безопасность хранения резервных копий не означает, что достаточно их шифровать, или что шифрование является обязательным. Безопасность также реализуется ограничением и контролем доступа к резервным копиям, серверам баз данных и сетям хранения данных. Обратите внимание, что шифрование и дешифрование файлов может занимать существенное время, особенно на больших объемах данных. Время шифрования/дешифрования также зависит от используемого алгоритма. Чем сложнее алгоритм, тем больше требуется времени и ресурсов.

Шифрование базы данных

При локальном хранении резервной копии у вас есть несколько вариантов повысить безопасность и надежность. В первую очередь, это шифрование. Например, создание логической резервной копии с помощью mysqldump выглядит следующим образом. 

Создайте файл с ключом шифрования.

Файл с ключом шифрования будет использоваться в качестве вашего пропуска для шифрования и дешифрования созданной резервной копии с помощью Percona Backup (Percona XtraBackup или Percona Backup for MongoDB).

$ openssl rand -base64 24 > /root/isolated_directory/keyfile.key

Теперь, когда ключ сгенерирован, его нужно сохранить в безопасном месте. Можно ограничить права доступа к этому файлу и, конечно же, сохранить его в изолированном и безопасном месте.

$ chmod -R 400 /root/isolated_directory

Создайте логический бэкап

/usr/bin/mysqldump --defaults-file=/etc/my.cnf  --flush-privileges --hex-blob --opt --master-data=2 --single-transaction --skip-lock-tables --triggers --routines --events --gtid  --databases db1 db2 db3 db4  |gzip -6 -c  |  openssl enc  -aes-256-cbc -pass file:/root/isolated_directory/keyfile.key  > /root/mysqldump_2020-12-27_schemaanddata.sql.gz

Если вы хотите больше узнать о шифровании баз данных, то прочитайте статью Database Backup Encryption - Best Practices.

Хранение ключей в хранилище

Для повышения безопасности ключ шифрования / токен лучше хранить  в отдельном хранилище (vault). Например, Hashicorp Vault. Если вы хотите узнать о том, как начать работу с Hashicorp Vault, то можете начать отсюда.

Если есть необходимость хранить ключи у сторонних провайдеров, то хорошим выбором будет AWS Secrets Manager. Это полностью управляемый сервис от Amazon, который интегрируется с Amazon KMS. Вы можете хранить и извлекать ключи шифрования, пароли к базам данных и учетные данные ssh.

Шифрование передаваемых данных

Размещение резервных копий в нескольких местах обеспечивает избыточность и повышает надежность вашего плана аварийного восстановления. Одной из основных причин хранения резервных копий в облаке является повышение избыточности для уменьшения рисков потери данных из-за их повреждения. Облака, как известно, являются безопасными, быстрыми, надежными и экономически эффективными. Для хранения данных в облаке обычно используются полностью управляемые сервисы, такие как Amazon S3, Google Cloud Storage и Azure Blob Storage. Есть также и альтернативы: Exoscale, Backblaze и ряд других S3-совместимых сервисов. Поскольку файлы передаются по открытым каналам связи, убедитесь, что используете TLS / SSL. В AWS S3 бакет можно настроить на обработку запросов только через TLS/SSL. Например, следующим образом:

{
  "Id": "ExamplePolicy",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSSLRequestsOnly",
      "Action": "s3:*",
      "Effect": "Deny",
       "Resource": [
         "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
         "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
       ],
       "Condition": {
         "Bool": {
           "aws:SecureTransport": "false"
         }
       },
       "Principal": "*"
     }
   ]
 }

Для других облачных хранилищ, например, Exoscale, можно использовать файл конфигурации .s3cfg, такой как этот:

[default]
host_base = sos-{zone}.exo.io
host_bucket = %(bucket)s.sos-{zone}.exo.io
access_key = $EXO_SOS_KEY
secret_key = $EXO_SOS_SECRET
use_https = True

Обратите внимание, что TLS / SSL обеспечивает шифрование данных при передаче их в облако. TLS — это более защищённая версия SSL, поэтому при возможности лучше используйте TLS.

Доступность хранилища базы данных

Резервные копии, хранящиеся в облаке, должны быть доступны при первой необходимости. Если при хранении резервных копий в облаке вы используете ротацию, то убедитесь, что у них достаточный срок хранения для RPO (Recovery Point Objective), определенного вашей организацией или компанией. При хранении в облаке вы также должны думать о сроках хранения с точки зрения использования ресурсов. В этом случае полезно определить жизненный цикл резервных копий. Для этого можно использовать инструменты, предлагаемые облачными провайдерами.

Доступность хранилища означает, что будет обеспечена необходимая скорость и пропускная способность, когда вам понадобится получить резервные копии для восстановления данных. Обратите внимание, что это должно быть частью вашего плана аварийного восстановления. Обязательно убедитесь, что ваш RTO (Recovery Time Objective) протестирован и соответствует ожидаемому времени выполнения восстановления. Время, в течение которого выполняется восстановление данных, непрерывность бизнеса и время простоя, зависят от того, когда ваша база данных будет полностью функциональна или, по крайней мере, будет в онлайне и сможет обслуживать наиболее критичные запросы. Бизнес должен работать постоянно и быть непрерывным.

Экономическая эффективность

Избыточность резервных копий и управление их жизненным циклом также влекут за собой затраты. Для небольших и средних предприятий это может и не проблема, но для организаций и компаний, которые управляют большими объемами данных, это может стать серьезным аргументом для хранения резервных копий в облаках. Но хранение данных не бесплатно. Вам стоит определить и выбрать подходящий план хранения файлов и провайдера, соответствующего вашим требованиями.  

Некоторые небольшие организации могут хранить резервные копии в файловом хранилище, например, в Google Drive или Microsoft OneDrive.

Но не забывайте, что для резервных копий также требуются метаданные и еще могут быть инкрементальные копии, которые гораздо удобнее хранить в объектном хранилище. Также объектные хранилища более гибки и предоставляют больше возможностей, таких как ACL (списки контроля доступа), географическая привязка и гибкая стоимость, зависящая от выбранного объема хранения и ресурса. По сути, стоимость объектных хранилищ очень выгодна: вы можете ограничить доступность файлов, использовать жизненный цикл, региональную / географическую привязку, настраивать производительность сервера или пропускную способность при отправке и/или получении данных.

Давайте сравним затраты на примерах.

Для начала рассмотрим класс хранилищ Amazon AWS S3 Standard и приведем примерный расчет стоимости. Обратите внимание, что S3 Standard хорошо подходит для хранения любых данных общего назначения и обычно используется для данных, к которым часто обращаются. Другие классы хранилищ вы можете посмотреть на странице AWS S3.

Для США Северная Вирджиния (US N. Virginia) стоимость будет следующая:

Для Запада США (Северная Калифорния), US West (Northern California) стоимость другая.

Теперь вы видите, что стоимость зависит от региона.

С другой стороны, цена в Google Cloud Storage за Standard Storage в Южной Каролине (us-east1) (South Carolina) начинается с $0,20 в месяц. Но если данные переместить из  US-EAST1 в NORTHAMERICA-NORTHEAST1, то цена уже будет $0,01 за ГБ.

А если посмотреть на цены Oracle Storage Cloud, то объектное хранилище начинается с $0,0255, а запросы к хранилищу с $0,0034. Более того, у них есть Block Volume Performance Units, которые начинаются с $0,0017, и вы можете выбрать нужный тип VPU.

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

Автоматизация резервного копирования

При автоматизации резервного копирования баз данных, будь то Percona Server for MySQL/MariaDB или Percona Server for MongoDB, лучше всегда использовать программное обеспечение, на которое вы сможете положиться.

Есть скрипты с открытым исходным кодом, которые можно попробовать использовать. Или написать свои и использовать Ansible, Chef, Puppet или SaltStack. Для корпоративного использования есть ClusterControl, который может управлять всем, что вам нужно. Он поддерживает создание резервных копий Percona Server for MySQL, Percona Server for MongoDB, MySQL, MariaDB и MongoDB. Это базы данных с открытым исходным кодом, которые вы можете использовать с Percona Backup Tools, поддерживаемые ClusterControl.

В ClusterControl вы можете создать политику резервного копирования и запускать ее вручную или автоматически. Самое замечательное то, что он позволяет сохранять резервные копии сразу в несколько мест: локально и в облака. В настоящее время есть поддержка AWS, GCP и Azure. Вы можете прочитать пост о том как создавать резервные копии, а затем отправлять их в облако. 

В качестве альтернативы можно использовать Backup Ninja — это SaaS-платформа (Software-as-a-Service), которая представляет собой простое, но эффективное решение для управления резервным копированием баз данных и файлов. Backup Ninja поддерживает множество облачных провайдеров, которыми вы, возможно, раньше не пользовались, и это открывает для вас новые возможности. Вы можете пользоваться вашим текущим облачным хранилищем, в котором нет автоматизации резервного копирования. Посмотрите список партнеров облачных хранилищ. Этот сервис очень хорошо продуман и предлагает выполнение резервного копирования баз данных по расписанию, восстановление баз данных, избыточное хранение, сжатие, безопасность и шифрование. Поддерживается как логический, так и бинарный бэкап. Как полный, так и инкрементный. Есть резервное копирование файлов. Цена начинается c $40. Backup Ninja можно использовать и бесплатно, что позволит вам иметь одну резервную копию на агента в день и одно восстановление резервной копии на агента в день, но только локальное хранилище.

Перевод статьи подготовлен в преддверии старта курса «Базы данных».

А всех желающих приглашаем на бесплатный демо-урок по теме: «MySQL NDB Cluster — шардинг». На занятии участники вместе с экспертом разберут NDB кластер, особенности архитектуры и компоненты, а также поработают на стенде.