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

Применимо к:Управляемый экземпляр SQL Azure

• База данных SQL Azure
• Управляемый экземпляр SQL Azure

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

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

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

Резервные копии базы данных являются важной частью любой стратегии непрерывности бизнес-процессов и аварийного восстановления, так как они помогают защитить данные от повреждения или удаления. Управляемый экземпляр SQL Azure предоставляет полностью управляемые и автоматизированные резервные копии ядра СУБД SQL Server. Эти резервные копии позволяют восстановить базу данных до определенной точки во времени в течение настроенного периода хранения до 35 дней. Однако если правила защиты данных требуют, чтобы резервные копии были доступны в течение длительного времени (до 10 лет), можно настроить политики долгосрочного хранения (LTR) для каждой базы данных.

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

  

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

  

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

  Результат:

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

  

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

  

Предупреждение

• Геовосстановление отключено, как только база данных обновляется, чтобы использовать локально избыточное или избыточное между зонами хранилище.
• Схемы избыточности хранилища отображают все регионы с несколькими зонами доступности (multi-az). Однако существуют некоторые регионы , которые предоставляют только одну зону доступности и не поддерживают ZRS или GZRS.

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

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

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

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

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

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

  Важно!

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

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

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

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

Свойства резервного копирования	PITR	Геовосстановление	LTR
Типы резервного копирования SQL	Полные, разностные и резервные копии журналов транзакций.	Реплицированные копии резервных копий PITR.	Только полные резервные копии.
Целевая точка восстановления (RPO)	Приблизительно 10 минут на основе размера вычислительных ресурсов и объема активности базы данных.	До одного часа, на основе георепликации. 1	Одна неделя (или согласно пользовательской политике).
Целевое время восстановления (RTO)	Восстановление обычно занимает менее 12 часов, но может занять больше времени в зависимости от размера и действия. См. раздел Восстановление.	Восстановление обычно занимает менее 12 часов, но может занять больше времени в зависимости от размера и действия. См. раздел Восстановление.	Восстановление обычно занимает менее 12 часов, но может занять больше времени в зависимости от размера и действия. См. раздел Восстановление.
Сохранение	От 1 до 35 дней.	Включено по умолчанию, в соответствии с источником. 2	Выключено по умолчанию. Срок хранения составляет до 10 лет.
Служба хранилища Azure	Геоизбыточность по умолчанию. При необходимости можно настроить избыточное между зонами или локально избыточное хранилище.	Доступно, если в качестве избыточности хранилища резервных копий PITR задана геоизбыточность. Недоступно, если хранилище резервного копирования PITR является избыточным по зонам или локально избыточным.	Геоизбыточность по умолчанию. Можно настроить избыточное по зонам или локально избыточное хранилище.
Настройка резервных копий в качестве неизменяемых	Не поддерживается	Не поддерживается	Не поддерживается
Восстановление новой базы данных в том же регионе	Поддерживается	Поддерживаемые	Поддерживается
Восстановление новой базы данных в другом регионе	Не поддерживается	Поддерживается в любом регионе Azure	Поддерживается в любом регионе Azure
Восстановление новой базы данных в другой подписке	Поддерживается	Не поддерживается 3	Не поддерживается 3
Восстановление с помощью портал Azure	Да	Да	Да
Восстановление с помощью PowerShell	Да	Да	Да
Восстановление с помощью Azure CLI	Да	Да	Да

^{1 Для критически важных для бизнеса приложений, которые требуют больших баз данных и должны обеспечить непрерывность бизнес-процессов, см . группы отработки отказа.}

^{2 Все резервные копии PITR хранятся в геоизбыточное хранилище по умолчанию, то есть геовосстановление включается по умолчанию.}

^{3 Решение заключается в восстановлении на новом сервере и использовании перемещения ресурсов для перемещения сервера в другую подписку.}

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

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

Операция	Портал Azure	Azure CLI	Azure PowerShell
Изменение периода хранения резервных копий	/ База данных SQL Управляемый экземпляр SQL	/ База данных SQL Управляемый экземпляр SQL	/ База данных SQL Управляемый экземпляр SQL
Изменение периода долгосрочного хранения резервных копий	/ База данных SQL Управляемый экземпляр SQL	/ База данных SQL Управляемый экземпляр SQL	/ База данных SQL Управляемый экземпляр SQL
Восстановление базы данных на момент времени	/ База данных SQL Управляемый экземпляр SQL	/ База данных SQL Управляемый экземпляр SQL	/ База данных SQL Управляемый экземпляр SQL
восстановлением удаленной базы данных;	/ База данных SQL Управляемый экземпляр SQL	/ База данных SQL Управляемый экземпляр SQL	/ База данных SQL Управляемый экземпляр SQL
Восстановление базы данных из Хранилище BLOB-объектов Azure			Управляемый экземпляр SQL

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

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

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

• Новые базы данных: сразу после создания, восстановления или восстановления базы данных выполняется изменение избыточности резервных копий, инициируется первая полная резервная копия. Эта резервная копия обычно завершается в течение 30 минут, хотя для больших баз данных может потребоваться больше времени.

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

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

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

Важно!

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

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

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

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

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

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

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

Важно!

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

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

Важно!

Резервные копии для удаленной базы данных хранятся для восстановления на определенный момент времени (PITR), что может увеличить затраты на хранилище по мере хранения резервных копий, даже если база данных удаляется. Чтобы сократить затраты, можно задать период хранения резервных копий в 0 дней, но только для удаленных баз данных. Для обычных баз данных минимальный срок хранения составляет 1 день.

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

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

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

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

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

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

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

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

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

Важно!

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

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

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

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

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

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

Стоимость хранилища службы Backup

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

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

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

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

• Locally redundant price = published price
• Zone-redundant price = published price x 1.25
• Geo-redundant price = published price x 2
• Geo-zone-redundant price = published price x 3.4

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

Примечание.

Счет Azure показывает только избыточное потребление хранилища резервных копий, а не все потребление хранилища резервных копий. Например, в гипотетическом сценарии, если вы подготовили 4 ТБ хранилища данных, вы получите 4 ТБ свободного места в хранилище резервных копий. Если вы используете в общей сложности 5,8 ТБ дискового пространства, счет Azure отображает только 1,8 ТБ, так как плата взимается только за избыточное хранилище резервных копий, которое вы использовали.

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

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 ГБ использования в течение нескольких часов до 372 (первая половина месяца). Для часов с 373-го по 744-й (вторая половина месяца) она сообщит об использовании 2 ГБ. Это использование будет агрегировано до окончательного счета за 1116 ГБ в месяц. Затраты на хранение не увеличиваются немедленно. Они постепенно увеличиваются каждый день, так как резервные копии растут до максимального периода хранения в течение 14 дней.

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

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

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

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

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

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

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

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

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

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

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

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

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

Важно!

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

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

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

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

Для обеспечения дополнительной целостности резервных копий все резервные копии базы данных создаются с параметром CHECKSUM. Автоматическое тестирование автоматических резервных копий баз данных командой разработчиков SQL Azure в настоящее время недоступно для Управляемый экземпляр SQL Azure. Запланируйте восстановление резервного копирования и DBCC CHECKDB в базах данных в Управляемый экземпляр SQL вокруг рабочей нагрузки.

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

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

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

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

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

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

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

Важно!

Политики Azure не применяются при создании базы данных с помощью T-SQL. Чтобы применить расположение данных при создании базы данных с помощью T-SQL, используйте local или ZONE в качестве входных данных для параметра BACKUP_STORAGE_REDUNDANCY в инструкции CREATE DATABASE.

Соблюдение закона

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

Примечание.

В статье об изменении параметров автоматического резервного копирования приведены инструкции по удалению персональных данных с устройства или службы и их можно использовать для поддержки ваших обязательств в соответствии с GDPR. Общие сведения о GDPR см. в разделе GDPR Центра управления безопасностью Майкрософт и в разделе GDPR на портале Service Trust Portal.

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

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