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

Применимо к: База данных SQL Azure

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  

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

  

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

  Результат:

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

  

• Геозонально-избыточное хранилище (GZRS): Геозонально-избыточное хранилище (GZRS) сочетает высокий уровень доступности, обеспечиваемый избыточностью в зонах доступности (ZRS), с защитой от региональных сбоев, обеспечиваемой георепликацией (GRS). В GZRS Azure синхронно копирует ваши резервные копии через три зоны доступности Azure в основной области и асинхронно три раза в одну физическую локацию в парной вторичной области.

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

  Результат:

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

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

    На следующей диаграмме показано, как данные реплицируются с помощью GZRS или RA-GZRS:

  

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

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

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

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

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

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

  Внимание

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

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

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

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

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

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

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

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

Сведения о времени восстановления см. в RTO и RPO.

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

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

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

Экспорт базы данных

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

Чтобы экспортировать База данных SQL Azure, рассмотрите другие альтернативы.

• Когда нужно экспортировать базу данных для архивирования или для переноса на другую платформу, экспортируйте схему и данные базы данных в BACPAC-файл . BACPAC-файл — это ZIP-файл с расширением BACPAC, содержащий метаданные и информацию из базы данных. Вы можете хранить файл BACPAC в хранилище Azure Blob или в локальном хранилище. Позже вы сможете импортировать его обратно в База данных SQL Azure, Управляемый экземпляр SQL Azure или экземпляр SQL Server.
• Вы также можете импортировать или экспортировать базу данных SQL Azure с помощью приватного канала или импортировать или экспортировать базу данных SQL Azure без предоставления доступа к серверу службам Azure.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Длительное хранение

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

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

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

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

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

Вы можете включить долгосрочное сохранение гипермасштабных баз данных, созданных или перенесённых с других уровней сервиса. Если вы пытаетесь включить LTR для базы данных гипермасштабирования, где она еще не поддерживается, вы получите следующую ошибку: "Произошла ошибка при включении долгосрочного хранения резервных копий для этой базы данных. Пожалуйста, свяжитесь с поддержкой Microsoft, чтобы обеспечить долгосрочное сохранение резервных копий.» В таком случае свяжитесь с поддержкой Microsoft и создайте заявку для разрешения вопроса.

Стоимость архивного хранилища

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

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

DTU-модель

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

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

Модель vCore

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

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

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

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

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

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

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 Billing агрегирует это потребление и показывает использование 744 ГБ за весь месяц. Стоимость зависит от скорости гигабайтов в месяц в вашем регионе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

База данных SQL Azure автоматически справляется с определёнными типами повреждений данных, используя встроенные методы при необходимости, без потери данных. В База данных SQL Azure ядро СУБД SQL Database выполняет проверку страниц при резервном копировании, управляемом службой, и при каждой операции восстановления. Все проблемы, обнаруженные во время проверки целостности, приводят к оповещению команды инженеров.

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, если вы включите политику «Azure SQL DB должен избегать использования резервного копирования GRS», пользователи не смогут создавать базы данных с хранением по умолчанию как глобально избыточным хранилищем. Политика запрещает пользователям использовать GRS и возвращает сообщение об ошибке: «Настройка типа резервного хранилища на 'Standard_RAGRS' не удалось при создании или обновлении базы данных.»

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

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

• Дополнительные сведения о других решениях для обеспечения непрерывности бизнес-процессов в SQL-базах данных см. в разделе Обзор непрерывности бизнес-процессов.
• Сведения об изменении параметров резервного копирования см. в разделе "Изменение параметров".
• Чтобы восстановить резервную копию, см. статью "Восстановление с помощью резервных копий" или "Восстановление базы данных до точки во времени" с помощью PowerShell.
• Сведения о настройке, управлении и восстановлении из долгосрочного хранения автоматических резервных копий в Хранилище BLOB-объектов Azure см. в статье "Управление долгосрочным хранением резервных копий".
• Сведения об Управляемом экземпляре SQL Azure см. в разделе «Автоматизированные резервные копии для Управляемого экземпляра SQL».