Поделиться через

Резервное копирование постоянных групп доступности SQL Server

  • Статья

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

Примечание.

  • Резервное копирование баз данных базовой группы доступности не поддерживается в Azure Backup.
  • Дополнительные сведения о поддерживаемых конфигурациях и сценариях можно найти в матрице резервной копии SQL.

Параметры резервного копирования, используемые группой доступности SQL Azure Backup, поддерживают полные и разностные резервные копии только из первичной реплики. Таким образом, эти задания резервного копирования всегда выполняются на основном узле независимо от настроек резервного копирования. При определении узла, на котором будут созданы полные резервные копии журналов транзакций или простые копии, учитываются предпочтения резервного копирования групп доступности.

Предпочтения резервного копирования групп доступности Выполнение полных и разностных резервных копий Резервные копии журналов или простые копии поступают из
Основной Первичная реплика Первичная реплика
Только вторичная Первичная реплика Любая из вторичных реплик
Предпочтение вторичной Первичная реплика Вторичные реплики являются предпочтительными, но резервные копии также могут выполняться на первичной реплике.
Нет/любая Первичная реплика Любая реплика

Расширение резервной копии рабочей нагрузки устанавливается на узле при регистрации в службе Azure Backup. Если база данных группы доступности настроена для резервного копирования, расписания резервного копирования отправляются на все зарегистрированные узлы группы доступности. Расписания запускаются на всех узлах группы доступности и расширениях резервной копии рабочей нагрузки на этих узлах синхронизируются между собой, чтобы решить, какой узел может выполнить резервное копирование. Выбор узла зависит от типа резервной копии и предпочтений касательно резервного копирования, как описано в разделе 1.

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

Примечание.

Azure Backup не учитывает приоритеты или реплики резервного копирования при принятии решения о выборе из вторичных реплик.

Регистрация узлов группы доступности в хранилище Служб восстановления

Хранилище служб восстановления поддерживает резервное копирование баз данных только из виртуальных машин в том же регионе и подписке, что и хранилище.

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

Настройка резервных копий для баз данных группы доступности завершается ошибкой с кодом FabricSvcBackupPreferenceCheckFailedUserError , если указанные выше условия не выполнены.

Рассмотрим описанное ниже развертывание группы доступности в качестве примера.

Схема развертывания группы доступности в качестве примера.

В зависимости от конкретного примера развертывания группы доступности следует учитывать различные аспекты.

  • Так как основной узел находится в регионе 1 и подписке 1, хранилище Служб восстановления (хранилище 1) должно находиться в регионе 1 и подписке 1 для защиты этой группы доступности.
  • VM3 Не удается зарегистрировать в Vault 1, так как он находится в другой подписке.
  • VM4 Не удается зарегистрировать в Vault 1, так как он находится в другом регионе.
  • Если параметр резервного копирования — только вторичное, VM1 (основная) и VM2 (вторичная) должны быть зарегистрированы в хранилище 1 (поскольку для полных резервных копий требуется первичный узел, а для журналов — вторичный). Для других настроек резервного копирования VM1 (основная) должна быть зарегистрирована в хранилище 1, VM2 является необязательной (так как все резервные копии могут выполняться на основном узле).
  • Хотя VM3 можно зарегистрировать в хранилище 2 в подписке 2, а базы данных группы доступности будут затем отображаться для защиты в хранилище 2, из-за отсутствия основного узла в хранилище 2 настройка резервного копирования завершится ошибкой.
  • Аналогичным образом, хотя виртуальная машина 4 может быть зарегистрирована в хранилище 4 в регионе 2, настройка резервных копий завершится ошибкой, так как основной узел не зарегистрирован в хранилище 4.

Отработка отказа

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

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

Примечание.

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

На основе приведенного выше примера развертывания группы доступности рассмотрим различные возможности отработки отказа.

  • Переход на виртуальную машину 2
    • Полные и разностные резервные копии будут выполняться из VM2.
    • Полные резервные копии журнала и простые копии будут выполняться из VM1 или VM2 в соответствии с настройками резервного копирования.
  • Отработка отказа на VM3 (другая подписка)
    • Так как резервные копии не настроены в хранилище 2, они не будут выполняться.
    • Если параметр резервного копирования не является только вторичным, резервные копии можно настроить сейчас в хранилище 2, так как основной узел зарегистрирован в этом хранилище. Но это может привести к конфликтам или сбоям при резервном копировании. Дополнительные сведения см. в статье Настройка резервного копирования для группы доступности с несколькими регионами.
  • Отработка отказа на VM4 (другой регион)
    • Так как резервные копии не настроены в хранилище 4, они не будут выполняться.
    • Если параметр резервного копирования не является вторичным, резервные копии теперь можно настроить в Хранилище 4, так как основной узел зарегистрирован в этом хранилище. Но это может привести к конфликтам или сбоям при резервном копировании. Дополнительные сведения см. в статье Настройка резервного копирования для группы доступности с несколькими регионами.

Настройка резервного копирования для группы доступности с несколькими регионами

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

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

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

  • Полные и разностные резервные копии будут успешно выполняться только в хранилище с основным узлом. Эти резервные копии в других хранилищах будут завершаться сбоем.

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

    Примечание.

    Существует жесткий лимит в 15 дней, после которого резервное копирование журналов начнет давать сбои.

  • Полные простые резервные копии будут работать во всех хранилищах.

  • Защита в каждом хранилище рассматривается как отдельный источник данных и оплачивается отдельно.

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

На основе приведенного выше примера развертывания группы доступности выполните шаги для включения резервного копирования со всех узлов. Предполагается, что параметры резервного копирования соблюдаются при выполнении всех шагов.

Шаг 1. Включение резервного копирования в регионе 1, подписка 1 (хранилище 1)

Так как первичный узел находится в регионе и подписке, обычные шаги по включению резервного копирования сработают.

Шаг 2. Включение резервного копирования в регионе 1, подписка 2 (хранилище 2)

  1. Отработка отказа группы доступности на VM3 с тем, чтобы первичный узел находился в хранилище 2.
  2. Настройка резервного копирования для баз данных группы доступности в хранилище 2.
  3. На этом этапе:
    1. Полные или разностные резервные копирования в хранилище 1 завершатся сбоем, так как ни один из зарегистрированных узлов не может принять эту резервную копию.
    2. Резервные копии журналов будут успешно выполнены в Хранилище 1, пока резервное копирование журналов не будет выполнено в Хранилище 2 и прерывает цепочку журналов для Хранилища 1.
  4. Восстановление размещения группы доступности в VM1.

Шаг 3. Включение резервного копирования в регионе 2, подписка 1 (хранилище 4)

Такой же, как и шаг 2.

Резервное копирование группы доступности, охватывающей Azure и локальную среду

Azure Backup для SQL Server нельзя запускать локально. Если первичный узел находится в Azure и параметры резервного копирования выполняются узлами в Azure, можно следовать приведенному выше руководству для группы доступности с несколькими регионами, чтобы включить резервное копирование для реплик в Azure. Если происходит отработка отказа на локальный узел, то все полные и разностные резервные копии в Azure будут завершаться сбоем. Резервные копии журналов могут продолжаться до тех пор, пока не произойдет прерывание цепочки журналов/ 15 дней.

Регулирование для заданий резервного копирования в базе данных группы доступности

В настоящее время ограничения на регулирование резервного копирования применяются на уровне отдельных компьютеров. Ограничение по умолчанию: 20 — если одновременно запущено более 20 резервных копий, первые 20 будут запущены, а другие будут помещены в очередь. После выполнения заданий будут запущены находящиеся в очереди.

Можно изменить это значение на меньшее, если одновременные операции резервного копирования вызывают чрезмерное использование памяти, операций ввода-вывода и ЦП на узле. Так как регулирование находится на уровне узла, наличие несбалансированных узлов группы доступности может привести к проблемам синхронизации резервных копий. Чтобы лучше понять это, рассмотрим пример группы доступности с двумя узлами.

Допустим, на первом узле есть 50 автономных защищенных баз данных, и оба узла имеют 5 защищенных баз данных группы доступности. Фактически узел 1 содержит 55 заданий резервного копирования баз данных, в то время как узел 2 — только 5. Кроме того, все эти резервные копии настроены на выполнение в одно и то же время, каждый час. На этом этапе все 55 резервных копий будут запущены на узле 1, а 35 окажутся в очереди. Некоторые из них могут быть резервными копиями базы данных группы доступности. Но на узле 2 резервные копии базы данных группы доступности будут работать без организации очереди.

Так как задания базы данных AG ставятся в очередь на одном узле и выполняются на другом, синхронизация резервных копий (упомянутая в разделе 6) не будет работать должным образом. Узел 2 может предположить, что узел 1 не работает, поэтому задания от него не поступают для синхронизации. Это может привести к прерыванию цепочки журналов или дополнительным резервным копиям, так как оба узла могут принимать резервные копии независимо.

Аналогичная проблема может возникнуть, если количество защищенных баз данных группы доступности превышает предел регулирования. В таком случае резервное копирование для, скажем, DB1 может быть поставлено в очередь на узле 1, тогда как оно выполняется на узле 2.

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

  • Для группы доступности с 2 узлами установите для параметра резервного копирования значение только Primary или Secondary — тогда только один узел сможет выполнять резервное копирование, а другой всегда будет запасным.
  • Для группы доступности, имеющей более 2 узлов, установите для параметра резервного копирования значение Primary — тогда только первичный узел сможет выполнять резервное копирование, а остальные будут запасными.

Выставление счетов за резервные копии группы доступности

Как и в случае с отдельным экземпляром SQL, один экземпляр группы доступности, для которого создана резервная копия, считается одним защищенным экземпляром. За общий размер внешней части всех защищенных баз данных в экземпляре выставляются счета. Рассмотрим следующее развертывание:

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

Защищенные экземпляры рассчитываются следующим образом:

Защищенный экземпляра / выставление счетов за экземпляр Базы данных, рассмотренные для вычисления внешнего размера
AG1 DB1, DB2
ГД2 БД 4
ВМ2 БД 3
ВМ3 DB6
ВМ 4 БД 5

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

Azure Backup считает экземпляр SQL или имя группы доступности / имя базы данных уникальным именем базы данных. Когда изолированная база данных была защищена, ее уникальное имя было ИмяИзолированногоЭкземпляра\ИмяБазыДанных. Когда она перемещается в пределах группы доступности, уникальное имя меняется на ИмяГруппыДоступности\ИмяБазыДанных. Резервное копирование изолированной базы данных начнет давать сбои с кодом ошибки: UserErrorBackupFailedStandaloneDatabaseMovedInToAG.

База данных должна быть настроена для защиты в пределах группы доступности. Она будет рассматриваться как новый источник данных с отдельной цепочкой точек восстановления. Старую защиту изолированной базы данных можно остановить с сохранением данных, чтобы избежать запуска и сбоев будущих операций резервного копирования. Аналогично, когда защищенная база данных группы доступности перемещается из группы доступности и становится изолированной базой данных, ее резервные копии начинают давать сбои с кодом ошибки: UserErrorBackupFailedDatabaseMovedOutOfAG.

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

Добавление/удаление узла в группе доступности

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

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

Отмена регистрации узла группы доступности из Azure Backup

Если узел является частью группы доступности, в которой есть одна или несколько баз данных, настроенных для резервного копирования, Azure Backup не позволяет отменить регистрацию этого узла. Это предотвращает будущие сбои резервного копирования в тех случаях, когда не удастся выполнить настройку резервного копирования без этого узла. Чтобы отменить регистрацию узла, сначала необходимо удалить его из группы доступности. Когда рабочий процесс отмены настройки узла завершается с очисткой этого узла, можно отменить регистрацию.

Восстановление базы данных из Azure Backup в группы доступности SQL группы доступности SQL не поддерживает непосредственное восстановление базы данных в группу доступности. База данных должна быть восстановлена в изолированный экземпляр SQL, а затем присоединена к группе доступности.

Сценарии повторного создания группы доступности для сервера базы данных SQL

Повторное создание группы доступности (AG), дублирование групп доступности и элементы резервного копирования отображаются как защищенные элементы или защищенные элементы в следующих сценариях:

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

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

  • Если данные резервного копирования из старой группы доступности не нужны, остановите операцию резервного копирования с помощью параметра "Остановить защиту" и удалите данные для старого элемента перед повторной созданием и планированием резервных копий в новой группе доступности.

    Внимание

    Остановить защиту и удаление данных — это деструктивная операция.

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

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

Вы узнаете, как выполнять следующие задачи: