Автоматическое резервное копирование в базе данных Azure SQL

Область применения: База данных SQL Azure

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

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

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

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

Для уровней служб, отличных от гипермасштабирования, база данных Azure SQL использует технологию ядра SQL Server для резервного копирования и восстановления данных. Базы данных с гипермасштабированием используют резервное копирование и восстановление на основе моментальных снимков хранилища. Благодаря традиционной технологии резервного копирования SQL Server большие базы данных имеют длительное время резервного копирования и восстановления. При использовании моментальных снимков гипермасштабирование обеспечивает возможность мгновенного резервного копирования и быстрого восстановления независимо от размера базы данных. Дополнительные сведения см. в статье "Гипермасштабирование резервных копий".

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

Azure SQL база данных создает:

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

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

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

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

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

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

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

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

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

    Схема, показывающая параметр локально избыточного хранилища (LRS).

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

    Схема, показывающая параметр хранилища, избыточного между зонами (ZRS).

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

    Результат:

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

    Схема с параметром геоизбыточного хранилища (GRS).

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

  • Геовосстановление отключается, как только база данных обновляется для использования локально избыточного хранилища или хранилища, избыточного между зонами.
  • Схемы избыточности хранилища отображают все регионы с несколькими зонами доступности (multi-az). Однако существуют некоторые регионы, которые предоставляют только одну зону доступности и не поддерживают ZRS.
  • Избыточность хранилища резервных копий для баз данных с гипермасштабированием можно задать только во время создания. Этот параметр нельзя изменить после подготовки ресурса. Чтобы обновить параметры избыточности хранилища резервных копий для существующей базы данных с гипермасштабированием с минимальным временем простоя, используйте активную георепликацию. Кроме того, можно использовать копию базы данных. Дополнительные сведения см. в разделе Резервные копии с Гипермасштабированием и избыточность хранилища.

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

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

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

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

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

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

    Важно!

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

  • Восстановите базу данных из определенной долгосрочной резервной копии отдельной базы данных или базы данных в пуле, если база данных настроена с помощью политики LTR. LTR позволяет восстановить более раннюю версию базы данных с помощью портал Azure, Azure CLI или Azure PowerShell для выполнения запроса на соответствие требованиям или запуска более старой версии приложения. Дополнительные сведения см. в статье Storing Azure SQL Database Backups for up to 10 years (Хранение резервных копий баз данных SQL Azure до 10 лет).

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

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

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

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

** Все резервные копии PITR хранятся в геоизбыточное хранилище по умолчанию, поэтому геовосстановление включено по умолчанию.

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

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

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

Операция Портал 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

Планирование резервного копирования

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

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

Важно!

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

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

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

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

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

Базы данных уровня "Гипермасштабирование" используют другой механизм планирования резервного копирования. Дополнительные сведения см. в разделе "Планирование резервного копирования с гипермасштабированием".

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

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

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

Важно!

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

Мониторинг потребления

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

Снимок экрана: выбор потребления резервных копий базы данных в портал Azure.

Инструкции по мониторингу потребления в гипермасштабировании см. в разделе "Мониторинг потребления резервных копий с гипермасштабированием".

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

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

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

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

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

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

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

Краткосрочное хранение резервных копий для баз данных уровня "Гипермасштабирование" составляет от 1 до 35 дней в предварительной версии. Дополнительные сведения см. в разделе об управлении хранением резервных копий при гипермасштабировании.

Разностные резервные копии можно настроить как раз в 12 часов, так и один раз в 24 часа. 24-часовая разностная частота резервного копирования может увеличить время, необходимое для восстановления базы данных, по сравнению с 12-часовой частотой. В модели виртуальных ядер частота разностных резервных копий по умолчанию — один раз в 12 часов. В модели DTU частота по умолчанию — один раз в 24 часа.

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

За исключением баз данных уровня "Базовый", можно изменить период хранения резервных копий для каждой активной базы данных в диапазоне от 1 до 35 дней. Как описано в разделе "Потребление хранилища резервных копий", резервные копии, хранящиеся для включения PITR, могут быть старше периода хранения. Если вам нужно хранить резервные копии дольше, чем максимальный краткосрочный срок хранения в 35 дней, можно включить долгосрочное хранение.

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

Важно!

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

Длительный период удержания

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

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

Обновление избыточности хранилища резервных копий для существующей базы данных применяет изменение только к последующим резервным копиям, сделанным в будущем, а не к существующим резервным копиям. Все существующие резервные копии LTR для базы данных будут по-прежнему находиться в существующем blob-объекте хранилища. Новые резервные копии будут реплицироваться на основе настроенной избыточности хранилища резервных копий.

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

Затраты на хранилище резервных копий

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

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

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

Сведения о ценах см. на странице цен на базу данных Azure SQL.

Примечание

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

Модель с DTU

В модели с оплатой за DTU дополнительная плата за хранилище резервных копий баз данных и эластичных пулов не взимается. Цена на хранилище резервных копий является частью цены на базу данных или пул.

Модель с виртуальными ядрами

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

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

Затраты на хранилище резервных копий вычисляются по-разному для баз данных уровня "Гипермасштабирование". Дополнительные сведения см. в статье о затратах на хранилище резервных копий с гипермасштабированием.

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

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

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

Total billable backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - maximum pool data storage

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Снимок экрана: анализ затрат на хранилище резервных копий.

Важно!

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

Дополнительные сведения см. в статье Управление затратами для Базы данных SQL Azure.

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

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

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

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

Любые проблемы, обнаруженные во время проверки целостности, приведут к оповещению команде инженеров. Дополнительные сведения см. в разделе "Целостность данных" в База данных SQL.

Для обеспечения дополнительной целостности резервных копий все резервные копии базы данных создаются с параметром CHECKSUM.

Соответствие нормативным требованиям

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

Примечание

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

Использование Политики 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.

Дальнейшие действия