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

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

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

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

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

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

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

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

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

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

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

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

Управление отказом

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

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

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

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

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

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

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

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

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

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

  Примечание.

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

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

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

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

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

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

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

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

1. Переключите группу доступности на VM3, чтобы первичный узел находился в Vault 2.
2. Настройте резервное копирование для баз данных группы доступности (AG) в хранилище 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 будут запущены, а другие будут помещены в очередь. Когда выполнятся текущие задания, начнут выполняться те, которые находятся в очереди.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Снятие регистрации узла AG из Azure Backup

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

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

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

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

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

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

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

  Внимание

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

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

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

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

• Восстановление резервных копий баз данных SQL Server
• Управление резервными копиями баз данных SQL Server

Связанный контент

• Резервное копирование баз данных SQL Server на виртуальных машинах Azure с помощью Azure Backup с помощью REST API.
• Восстановление баз данных SQL Server на виртуальных машинах Azure с помощью REST API.
• Управление базами данных SQL Server на виртуальных машинах Azure с помощью портала Azure, Azure CLI, REST API.