Share via

Резервное копирование и восстановление в службе "База данных Azure для MariaDB"

  • Статья

Важно!

База данных Azure для MariaDB находится на пути выхода на пенсию. Настоятельно рекомендуется выполнить миграцию в База данных Azure для MySQL. Дополнительные сведения о переходе на База данных Azure для MySQL см. в статье "Что происходит с База данных Azure для MariaDB?".

В службе "База данных Azure для MariaDB" для сервера автоматически создаются резервные копии, которые сохраняются в локально избыточном или геоизбыточном хранилище, настроенном пользователем. Резервные копии можно использовать для восстановления сервера до точки во времени. Резервное копирование и восстановление данных являются важной частью любой стратегии непрерывности бизнес-процессов. Таким образом данные защищаются от случайного повреждения или удаления.

Резервные копии

База данных Azure для MariaDB выполняет резервное копирование файлов данных и журнала транзакций. При помощи этих резервных копий вы можете восстановить сервер до любой точки во времени в пределах заданного срока хранения резервных копий. По умолчанию срок хранения резервных копий составляет 7 дней. При желании можно задать срок хранения до 35 дней. Все резервные копии шифруются с помощью 256-битового шифрования AES.

Эти файлы резервных копий не предоставляются пользователю, и их невозможно экспортировать. Эти резервные копии можно использовать только для операций восстановления в базе данных Azure для MariaDB. Скопировать базу данных можно с помощью утилиты mysqldump.

Тип резервного копирования и частота зависят от серверного хранилища для серверов.

Тип и частота резервного копирования

Базовые серверы хранилища

Базовое хранилище — это серверное хранилище, поддерживающее серверы базового уровня. Резервное копирование на базовых серверах хранилища основано на моментальных снимках. Полный моментальный снимок базы данных выполняется ежедневно. Для базовых серверов хранилища не выполняется разностное резервное копирование, и все резервные копии моментальных снимков являются полными резервными копиями баз данных.

Создание резервных копий журналов транзакций происходит каждые 5 минут.

Серверы хранилища общего назначения объемом до 4 ТБ

Хранилище общего назначения — это серверное хранилище, поддерживающее серверы общего назначения и уровня с оптимизированного для операций в памяти. Для серверов с хранилищем общего назначения объемом до 4 ТБ полные резервные копии выполняются каждую неделю. Разностное резервное копирование выполняется дважды в день. Создание резервных копий журналов транзакций происходит каждые 5 минут. Резервные копии в хранилище общего назначения до 4-ТБ не основаны на моментальных снимках и используют пропускную способность ввода-вывода во время резервного копирования. Для больших баз данных (>1 ТБ) в хранилище объемом 4 ТБ рекомендуется рассмотреть

  • подготовку дополнительных операций ввода-вывода в секунду для резервного копирования или
  • или же переход на хранилище общего назначения, которое поддерживает объем до 16 ТБ, если базовая инфраструктура хранилища доступна в предпочитаемых регионах Azure. Нет дополнительных затрат на хранилище общего назначения, которое поддерживает до 16-ТБ хранилища. Чтобы получить помощь по миграции в хранилище 16-ТБ, откройте запрос в службу поддержки из портал Azure.

Серверы хранилища общего назначения объемом до 16 ТБ

В подмножестве регионов Azure все вновь подготовленные серверы могут поддерживать хранилище общего назначения объемом до 16 ТБ. Другими словами, хранилище до 16-ТБ — это хранилище общего назначения по умолчанию для всех регионов, где она поддерживается. Резервные копирования, находящиеся на этих серверах хранилища объемом до 16 ТБ, основаны на моментальных снимках. Первая полная резервная копия моментального снимка планируется сразу же после создания сервера. Первая полная резервная копия на основе моментального снимка сохраняется в качестве базовой резервной копии сервера. Последующие резервные копии моментальных снимков — это только разностные резервные копии.

Разностные резервные копии моментальных снимков создаются по крайней мере один раз в день. Разностные резервные копии моментальных снимков не происходят в фиксированном расписании. Разностное резервное копирование моментальных снимков выполняется каждые 24 часа, если только размер журнала транзакций (binlog в MariaDB) не превышает 50 ГБ с момента создания последней разностной резервной копии. В день разрешено создание не более шести разностных моментальных снимков.

Создание резервных копий журналов транзакций происходит каждые 5 минут.

Хранение архивных копий

Резервные копии сохраняются с учетом заданного на сервере периода хранения резервной копии. Период хранения можно установить от 7 до 35 дней. Срок хранения по умолчанию составляет 7 дней. Период хранения можно задать в процессе создания сервера или позже, изменив конфигурацию резервного копирования на портале Azure или в интерфейсе командной строки Azure.

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

  • Серверы с хранилищем до 4-ТБ будут хранить до двух полных резервных копий базы данных, всех разностных резервных копий и резервных копий журналов транзакций, выполняемых с самого раннего полного резервного копирования базы данных.
  • Серверы с хранилищем до 16-ТБ будут хранить полный моментальный снимок базы данных, все разностные моментальные снимки и резервные копии журналов транзакций за последние восемь дней.

Долгосрочного хранение резервных копий

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

географическое и локальное

В службе "База данных Azure для MariaDB" вы можете выбрать локально избыточное или геоизбыточное хранилище резервных копий в ценовой категории "Общего назначения" или "С оптимизацией для операций в памяти". Если резервные копии хранятся в геоизбыточное хранилище резервных копий, они не только хранятся в регионе, в котором размещен сервер, но и реплика в парном центре обработки данных. Благодаря этому сервер лучше защищен и его можно восстановить в другом регионе в случае аварии. На уровне "Базовый" предоставляется только локально избыточное хранилище резервных копий.

Переход с локально избыточного хранилища на хранилище резервных копий

Хранилище резервных копий (локально избыточное или геоизбыточное) можно настроить только на этапе создания сервера. После подготовки сервера невозможно изменить тип избыточности для хранилища резервных копий. Чтобы переместить хранилище резервных копий из локально избыточного хранилища в геоизбыточное хранилище, необходимо создать новый сервер и перенести данные, выполнив их дамп и восстановление — это единственный поддерживаемый вариант.

Стоимость хранилищ резервных копий

В службе "База данных Azure для MariaDB" бесплатно предоставляется хранилище резервных копий размером до 100 % объема подготовленного хранилища сервера. За дополнительный объем хранилища резервных копий взимается плата (за ГБ в месяц). Например, если вы подготовили сервер с 250 ГБ хранилища, у вас есть 250 ГБ дополнительного хранилища, доступного для резервного копирования серверов без дополнительной платы. Плата за использование хранилища для резервных копий свыше 250 ГБ рассчитывается в соответствии с моделью ценообразования.

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

Основным способом управления затратами на хранение резервных копий является установка соответствующего периода хранения резервных копий и выбор правильных параметров избыточности резервных копий в соответствии с необходимыми целями восстановления. Можно установить период хранения от 7 до 35 дней. Серверы общего назначения и оптимизированные для операций в памяти серверы могут использовать для резервных копий геоизбыточное хранилище.

Восстановление

В базе данных Azure для MariaDB при восстановлении создается новый сервер из резервных копий исходного сервера и восстанавливаются все содержащиеся на нем базы данных.

Есть два типа восстановления:

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

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

Важно!

Удаленные серверы могут быть восстановлены только в течение пяти дней с момента удаления резервных копий. Получить доступ к резервной копии базы данных и выполнить восстановление можно только из подписки Azure, в которой размещен сервер. Инструкции по восстановлению удаленного сервера см. в документированных действиях. Чтобы защитить ресурсы сервера после развертывания от случайного удаления или внесения непредвиденных изменений, администраторы могут использовать блокировки управления.

Восстановление на определенный момент времени

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

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

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

Геовосстановление

Сервер можно восстановить в другом регионе Azure, где служба доступна, если вы настроили сервер для геоизбыточного резервного копирования. Серверы, поддерживающие хранилище объемом до 4 ТБ, можно восстановить в геопарный регион или в любой регион, поддерживающий хранилище объемом до 16 ТБ. Для серверов, поддерживающих до 16 ТБ хранилища, георезервные копии можно восстановить в любом регионе, поддерживающем серверы объемом 16 ТБ. Список поддерживаемых регионов приведен в разделе Ценовые категории базы данных Azure для MariaDB.

Геовосстановление используется по умолчанию, когда сервер недоступен из-за аварии в регионе, в котором он размещен. Если из-за масштабной аварии в регионе приложение базы данных станет недоступным, сервер можно будет восстановить из геоизбыточных резервных копий на сервер в любом другом регионе. При геовосстановлении используется самая последняя резервная копия сервера. Существует задержка между моментом создания резервной копии и реплика в другой регион. Эта задержка может длиться до часа, поэтому в случае аварии возможна потеря данных за час или менее.

Важно!

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

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

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

Задачи после восстановления

После восстановления с помощью любого из механизмов восстановления необходимо выполнить следующие задачи, прежде чем данные и приложения станут доступными:

  • Если новый сервер заменит исходный, перенаправьте клиенты и клиентские приложения на новый сервер.
  • Убедитесь, что заданы соответствующие правила виртуальной сети, чтобы пользователи могли установить подключение. Эти правила не копируются с исходного сервера.
  • Убедитесь, что заданы соответствующие данные для входа и разрешений уровня базы данных.
  • Настройте оповещения соответствующим образом.

Следующие шаги

  • Дополнительные сведения о непрерывности бизнес-процессов см. в этой статье.
  • Сведения о восстановлении базы данных до точки во времени с помощью портала Azure приведены в этой статье.
  • Сведения о восстановлении базы данных до точки во времени с помощью интерфейса командной строки Azure можно найти в этой статье.