Автоматическое резервное копирование в Управляемом экземпляре SQL Azure

Область применения: Управляемый экземпляр SQL Azure

В этой статье описывается функция автоматического резервного копирования для Управляемого экземпляра SQL Azure.

Сведения об изменении параметров резервного копирования см. в статье Об изменении параметров автоматического резервного копирования для Управляемого экземпляра SQL Azure. Сведения о восстановлении резервной копии см. в статье "Восстановление базы данных из резервной копии в Управляемом экземпляре SQL Azure".

Что такое автоматическое резервное копирование базы данных?

Резервные копии базы данных являются важной частью любой стратегии непрерывности бизнес-процессов и аварийного восстановления, так как они помогают защитить данные от повреждения или удаления. В Управляемый экземпляр SQL Azure резервные копии модуля базы данных SQL Server автоматически создаются и администрируются корпорацией Майкрософт и хранятся в управляемых корпорацией Майкрософт учётных записях хранения Azure.

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

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

Управляемый экземпляр SQL Azure создает:

• Полные резервные копии каждую неделю.
• Дифференциальное резервное копирование каждые 12 или 24 часа.
• Резервное копирование журналов транзакций примерно каждые 10 минут.

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

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

Системные базы данных автоматически резервируются (за исключением физической master базы данных), но эти резервные копии в настоящее время не записаны в msdb.

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

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

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

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

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

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

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

  

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

  

• Геоизбыточное хранилище (GRS) — копирует резервные копии синхронно три раза в одном физическом расположении в основном регионе с помощью LRS. Затем система асинхронно копирует ваши данные в трех экземплярах в одно физическое местоположение в парном вторичном регионе.

  Результат:

  • Три синхронные копии в основном регионе в пределах одной зоны доступности.
  • Три синхронные копии в парном регионе в пределах одной зоны доступности, асинхронно скопированные из основного региона во вторичный регион.

  

• Геоизбыточное хранилище (GZRS) — объединяет высокий уровень доступности, предоставляемый избыточностью между зонами доступности с защитой от региональных сбоев, предоставляемых георепликацией. Данные в учетной записи GZRS копируются в трех зонах доступности Azure в основном регионе. Данные также реплицируются в дополнительный географический регион для защиты от региональных бедствий. В этом регионе также есть три синхронных копии в одной зоне доступности, скопированной из основного региона в дополнительный регион асинхронно.

  

Использование резервного копирования

Эти резервные копии позволяют выполнить следующие операции:

• Восстановите существующую базу данных до состояния на определённый момент времени в прошлом в пределах периода хранения с помощью портала Azure, Azure PowerShell, Azure CLI или REST API. Эта операция создает новую базу данных либо в том же экземпляре, что и исходная база данных, либо другой экземпляр в одной подписке и регионе. Он использует другое имя, чтобы избежать перезаписи исходной базы данных. Вы также можете использовать портал Azure, чтобы восстановить резервную копию базы данных, созданную на определенный момент времени, в экземпляр, находящийся в другой подписке, чем исходный экземпляр.

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

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

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

  Внимание

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

• Восстановите базу данных из долгосрочной резервной копии базы данных, если у базы данных настроена политика LTR. LTR позволяет восстановить старую версию базы данных с помощью портал Azure, Azure CLI или Azure PowerShell, чтобы выполнить запрос на соответствие или запустить старую версию приложения. Дополнительные сведения см. в статье "Долгосрочные резервные копии хранения" — База данных SQL Azure и Управляемый экземпляр SQL Azure.

Автоматическое резервное копирование на вторичных репликах

Автоматическое резервное копирование теперь выполняется из вторичной реплики на уровне обслуживания Business Critical. Так как данные реплицируются между процессами ядра СУБД SQL на каждом узле, служба резервного копирования принимает резервную копию из нечитаемых вторичных реплик. Эта конструкция гарантирует, что основная реплика остается посвященной основной рабочей нагрузке, а доступная для чтения вторичная реплика предназначена для рабочих нагрузок, связанных с чтением. Автоматическое резервное копирование на уровне службы Business Critical выполняется с вторичной реплики в большинстве случаев. Если автоматическая резервная копия завершается ошибкой во вторичной реплике, служба резервного копирования принимает резервную копию из первичной реплики.

Автоматическое резервное копирование на вторичных репликах:

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

Восстановление возможностей и функций

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

¹ Для критически важных для бизнеса приложений, которым требуются крупные базы данных и обеспечение непрерывности бизнес-процессов, см. группы отработки отказа.
² Все резервные копии PITR хранятся в геоизбыточное хранилище по умолчанию, то есть геовосстановление включается по умолчанию.
³ Резервные копии базы данных можно восстановить только в экземплярах с соответствующими политиками обновления или в политику обновления более поздней версии SQL Server. Например, резервная копия базы данных, полученная из экземпляра с политикой обновления SQL Server 2022, может быть восстановлена в экземпляре с политикой обновления SQL Server 2022, SQL Server 2025 или Always-up-to-date.
⁴ Обходной путь заключается в том, чтобы восстановить на новый сервер, а затем с помощью Resource Move переместить сервер в другую подписку.

Восстановление базы данных из резервной копии

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

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

Управляемый экземпляр SQL Azure автоматически управляет резервными копиями, создавая полные, разностные и резервные копии журналов транзакций. Этот процесс регулируется внутренним расписанием.

Начальное резервное копирование

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

Запланированные полные резервные копии

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

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

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

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

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

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

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

Управляемый экземпляр SQL Azure рассчитывает общий объём используемого хранилища резервных копий как совокупное значение. Каждый час это значение сообщается конвейеру выставления счетов Azure. Конвейер отвечает за агрегирование этого почасового использования для вычисления потребления в конце каждого месяца. После удаления базы данных потребление уменьшается по мере устаревания и удаления резервных копий. После удаления всех резервных копий, когда PITR становится невозможным, начисление платы прекращается.

Точная настройка использования хранилища резервных копий

Использование хранилища резервных копий в пределах максимального размера данных базы данных не тарифицируется. Избыточное потребление хранилища резервных копий зависит от рабочей нагрузки и максимального размера отдельных баз данных. Рассмотрите некоторые из следующих методов настройки для уменьшения потребления хранилища резервных копий:

• Сократите срок хранения резервных копий базы данных до минимального значения для ваших потребностей.
• Не выполняйте крупные операции записи, например перестроение индекса, чаще, чем это необходимо.
• При выполнении операций загрузки больших объемов данных рекомендуется использовать кластеризованные индексы columnstore и следовать соответствующим рекомендациям. Также рассмотрите возможность уменьшения числа некластеризованных индексов.
• В уровне служб общего назначения подготовленное хранилище данных более экономично, чем хранилище резервных копий. При постоянно высоких избыточных затратах на хранилище резервных копий можно увеличить хранилище данных, чтобы сэкономить на хранилище резервных копий.
• Используйте tempdb вместо постоянных таблиц в логике приложения для хранения временных результатов или временных данных.
• По возможности используйте локально избыточное хранилище резервных копий (например, среды разработки и тестирования).

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

Управляемый экземпляр SQL Azure обеспечивает как краткосрочное, так и долгосрочное хранение резервных копий. Краткосрочное хранение позволяет выполнять восстановление на определённый момент времени (PITR) в течение периода хранения для базы данных. Долгосрочное хранение предоставляет резервные копии для различных требований соответствия требованиям.

Краткосрочное хранение

Для всех новых, восстановленных и скопированных баз данных Управляемый экземпляр SQL Azure сохраняет достаточно резервных копий, чтобы разрешить PITR за последние 7 дней по умолчанию. Эту конфигурацию можно изменить в диапазоне от 1 до 35 дней. Служба принимает регулярные полные, разностные и резервные копии журналов, чтобы обеспечить восстановление баз данных в любой момент времени в течение периода хранения, определенного для базы данных или управляемого экземпляра.

Вы можете указать параметр избыточности хранилища резервных копий для STR при создании экземпляра, а затем изменить его позже. При изменении параметра избыточности резервного копирования после создания экземпляра новые резервные копии будут использовать новый параметр избыточности. Резервные копии, сделанные с помощью предыдущего параметра избыточности STR, не перемещаются или не копируются. Они остаются в исходной учетной записи хранения до истечения срока хранения. Как описано в разделе "Использование хранилища резервных копий", резервные копии, хранящиеся для включения PITR, могут быть старше периода хранения, чтобы обеспечить точное восстановление данных.

При удалении базы данных система сохраняет резервные копии таким же образом, что и для сетевой базы данных с определенным периодом хранения. Однако для удаленной базы данных срок хранения обновляется с 1–35 дней до 0-35 дней, что позволяет вручную удалять резервные копии. Если необходимо сохранить резервные копии дольше, чем максимальный краткосрочный срок хранения в течение 35 дней, можно включить долгосрочное хранение.

Долгосрочное хранение (LTR)

С помощью Управляемого экземпляра SQL можно настроить хранение полных резервных копий LTR на срок до 10 лет в хранилище BLOB-объектов Azure. После настройки политики LTR полные резервные копии автоматически копируются в другой контейнер хранилища.

Чтобы удовлетворять различные требования к соответствию, вы можете выбрать разные периоды хранения для полных резервных копий, создаваемых еженедельно, ежемесячно или ежегодно. Частота зависит от политики. Например, установка значения W=0, M=1, Y=0 приведёт к созданию ежемесячной LTR-копии. Дополнительные сведения о LTR см. в статье "Долгосрочные резервные копии хранения" — База данных SQL Azure и Управляемый экземпляр SQL Azure.

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

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

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

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

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

Стоимость хранилища резервных копий варьируется. Он зависит от выбранного варианта избыточности хранилища резервных копий и региона. Плата за хранение резервных копий взимается исходя из объёма в гигабайтах, используемого за месяц, по единому тарифу для всех резервных копий.

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

• Locally-redundant price (LRS) = Zone-redundant price (ZRS) = published price
• Geo-redundant price (GRS) = Geo-zone-redundant price (GZRS) = published price x 2

Сведения о ценах см. на странице с ценами на Управляемый экземпляр SQL Azure.

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

Total billable backup storage size = (total size of full backups + total size of differential backups + total size of log backups) – maximum instance data storage

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

В качестве упрощенного примера предположим, что база данных накопила 744 ГБ хранилища резервных копий и что эта сумма остается постоянной в течение всего месяца, так как база данных полностью неактивна. Чтобы преобразовать это совокупное потребление хранилища в почасовое использование, разделите его на 744,0 (31 день в месяц 24 часа в день). Управляемый экземпляр SQL сообщает в конвейер биллинга Azure, что база данных каждый час использовала 1 ГБ PITR-резервного копирования с постоянной скоростью. Выставление счетов Azure объединяет это потребление и показывает использование 744 ГБ в течение всего месяца. Стоимость зависит от скорости гигабайтов в месяц в вашем регионе.

Ниже приведен еще один пример. Предположим, что период хранения той же бездействующей базы данных увеличился с 7 до 14 дней в середине месяца. Это увеличение приведет к удвоению общей емкости хранилища резервных копий, которая составит 1488 ГБ. Управляемый экземпляр SQL будет отражать использование в объёме 1 ГБ с 1-го по 372-й час (то есть в первую половину месяца). Для часов с 373-го по 744-й (вторая половина месяца) она сообщит об использовании 2 ГБ. Это использование будет агрегировано до окончательного счета за 1116 ГБ в месяц. Затраты на хранение не увеличиваются немедленно. Они постепенно увеличиваются каждый день, так как резервные копии растут до максимального периода хранения в течение 14 дней.

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

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

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

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

Чтобы уменьшить размер всех разностных резервных копий, слишком большие разностные резервные копии, превышающие 750 ГБ и равные 75% размера базы данных, повышаются до полного резервного копирования, если последняя полная резервная копия была выполнена более 24 часов назад.

Мониторинг затрат

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

1. Добавьте фильтр для строки Имя службы.

2. В раскрывающемся списке выберите Управляемый экземпляр SQL для управляемого экземпляра.

3. Добавьте еще один фильтр для строки Подкатегория единицы измерения.

4. Чтобы отслеживать затраты на резервное копирование PITR, в раскрывающемся списке выберите хранилище резервных копий управляемого экземпляра pitr. Счетчики отображаются только в том случае, если существует потребление хранилища резервных копий.

   Чтобы отслеживать затраты на резервное хранилище LTR, в раскрывающемся списке выберите управляемый экземпляр SQL — хранилище резервных копий LTR. Счетчики отображаются только в том случае, если существует потребление хранилища резервных копий.

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

Зашифрованные резервные копии

Если ваша база данных зашифрована с помощью TDE (прозрачного шифрования данных), резервные копии, включая долгосрочные резервные копии (LTR), автоматически шифруются в неактивном состоянии. Все новые базы данных в Azure SQL настроены с включённым по умолчанию TDE. Дополнительные сведения о TDE см. в статье Прозрачное шифрование данных с помощью Управляемого экземпляра SQL.

Корпорация Майкрософт полностью отвечает за хранение и смену ключей для баз данных с помощью ключей, управляемых службой (SMK). Резервные копии PITR или LTR, созданные на основе экземпляров с включёнными TDE и SMK, могут быть восстановлены Microsoft.

Автоматические резервные копии, хранящиеся в управляемых Azure учетных записях хранения, автоматически шифруются хранилищем Azure. Дополнительные сведения о шифровании службы хранилища Azure для данных в состоянии покоя.

Распространенные проблемы с автоматическими резервными копиями из-за действий клиента

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

• Недостаточно хранилища для управляемого экземпляра SQL. Если хранилище, выделенное для вашего экземпляра, заполнено, автоматические резервные копии не принимаются.
• Определяемые пользователем задания или скрипты, которые убивают системные процессы, могут остановить автоматические операции резервного копирования.
• Неправильные параметры DNS могут препятствовать доступу управляемого экземпляра SQL к необходимым конечным точкам Azure, включая те, которые используются для резервного копирования, что приводит к сбоям резервного копирования.
• Журнал транзакций может заполниться из-за предотвратенного усечения вследствие неправильно настроенной репликации, функции захвата изменений данных (CDC) или переполненного хранилища на уровне экземпляра. Если журнал транзакций заполнен и его нельзя усечь, полные и дифференциальные резервные копии завершаются ошибкой, но резервные копии журналов все равно успешно выполняются, хотя файл журнала не усечен.

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

Целостность резервной копии

Все резервные копии баз данных используют CHECKSUM опцию обеспечения дополнительной целостности резервного копирования. В качестве дополнительного уровня защиты вы можете протестировать восстановление резервных копий и провести проверку целостности. Для получения дополнительной информации см. раздел «Целостность данных в База данных SQL Azure».

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

Для получения дополнительной информации см. раздел «Целостность данных в Управляемый экземпляр SQL Azure».

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

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

Политика Azure — это служба, которую можно использовать для создания политик для применения правил к ресурсам Azure, их назначения и управления ими. Политика Azure помогает обеспечить соответствие этим ресурсам корпоративным стандартам и соглашениям об уровне обслуживания. Дополнительные сведения см. в статье Обзор Политика Azure.

Встроенные политики избыточности хранилища резервных копий

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

Полный список встроенных определений политик для Управляемого экземпляра SQL см. в справочнике по политикам.

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

Резервные копии Управляемого экземпляра SQL Azure полностью управляются в подписках Azure, принадлежащих Майкрософт, с помощью безопасных внутренних учетных записей хранения Azure. Эти резервные копии недоступны во внешнем режиме, обеспечивая надежную изоляцию и защиту данных. В корпорации Майкрософт только серверные службы, такие как служба Backup-Restore, имеют доступ к созданию, копированию или восстановлению этих резервных копий. Инженеры Майкрософт, в том числе разработчики, не имеют постоянного доступа. Чтобы свести к минимуму воздействие и максимизировать безопасность, корпорация Майкрософт может получить доступ Just-In-Time (JIT) в соответствии со строгими элементами аудиторского контроля, если это абсолютно необходимо для устранения конкретных проблем клиентов.

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

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

Если период хранения по умолчанию не соответствует вашим требованиям соответствия, вы можете изменить период хранения PITR. Дополнительные сведения см. в разделе Изменение периода хранения резервных копий PITR.

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

• Общие сведения об обеспечении непрерывности бизнес-процессов с помощью Управляемого экземпляра Azure SQL
• Управление долгосрочным хранением резервных копий для Управляемого экземпляра SQL Azure
• Восстановление базы данных из резервной копии на управляемом экземпляре SQL Azure
• Описание использования хранилища резервных копий в Управляемом экземпляре SQL
• Точная настройка затрат на хранилище резервных копий для Управляемого экземпляра SQL