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

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

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

Примечание.

Azure Backup не поддерживает резервное копирование баз данных группы доступности Basic.

Поведение предпочтения резервного копирования по версии SQL Server

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

SQL Server 2022 и более ранних версий

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

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

SQL Server 2025 и более поздних версий

В SQL Server 2025 и более поздних версий вторичные реплики также поддерживают полные и разностные резервные копии. Предпочтения резервного копирования теперь управляют обоими типами резервных копий единообразно. Если выбрать Только вторичный или Предпочтительно вторичный, полные и разностные резервные копии больше не требуют использования основного узла.

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

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

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

Примечание.

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

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

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

SQL Server 2022 и более ранних версий:

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

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

SQL Server 2025 и более поздних версий:

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

Примечание.

Смягчение требования регистрации первичного узла зависит от версии SQL Server, определённой в процессе обнаружения базы данных группы доступности. Если какая-либо реплика в группе доступности использует SQL Server 2022 или более раннюю версию, для этой группы доступности по-прежнему действует требование о регистрации первичного узла.

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

Схема развертывания AG для справки.

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

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

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

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

  • SQL Server 2022 и более ранние версии: полные и разностные резервные копии продолжают выполняться на новом первичном узле, если он зарегистрирован в хранилище.
  • SQL Server 2025 и более поздние версии: полные и разностные резервные копии выполняются на узле, который соответствует параметру предпочтения резервного копирования. Для Только вторичная или Предпочтительно вторичная эти резервные копии могут выполняться на вторичной реплике.
  • Полные резервные копии журнала и простые копии будут продолжать поступать с первичного или вторичного узла в соответствии с настройками резервного копирования.

Примечание.

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

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

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

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

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

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

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

  • SQL Server 2022 и более ранних версий: полные и разностные резервные копии работают только в хранилище с основным узлом. Эти резервные копии в других хранилищах постоянно завершаются с ошибкой. В SQL Server 2025 и более поздних версиях это поведение изменяется для параметров Только вторичный и Предпочитать вторичный — см. SQL Server 2025: изменения резервного копирования многорегиональной группы доступности.

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

    Примечание.

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

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

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

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

SQL Server 2025: изменения резервного копирования групп доступности в нескольких регионах

При использовании SQL Server 2025 полные и разностные резервные копии больше не требуют основного узла. Это изменение означает:

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

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

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

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

  • Двухузловая группа доступности: установите параметр предпочтения для резервного копирования на Только вторичная реплика или Основная реплика.
  • 3+ группа доступности узлов: задайте для параметра резервного копирования значение Primary.

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

На основе вышеупомянутого примера развертывания 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Добавление узла в AG или его удаление из AG

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

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

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

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

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

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

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

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

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

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

    Внимание

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

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

Рекомендации по резервному копированию SQL Server 2025 AG

Изменения предпочтений резервного копирования после настройки

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

Координация резервного копирования AG в нескольких регионах

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

Поддержка резервного копирования на основе снимков

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

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

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

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

  • Last updated on