Резервное копирование и восстановление в службе "База данных 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 можно найти в этой статье.