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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  

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

  

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

  Результат:

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

  

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

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

  Результат:

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

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

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

  

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

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

• Восстановите существующую базу данных до точки во времени в течение периода хранения с помощью портал 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 лет).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модель с DTU

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

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

База данных SQL Azure вычисляет общее оплачиваемое хранилище резервных копий как накопительное значение во всех файлах резервного копирования. Каждый час это значение сообщается конвейеру выставления счетов 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, в раскрывающемся списке выберите хранилище резервных копий с одним пулом эластичных пулов для одной базы данных или пула эластичных баз данных. Счетчики отображаются только в том случае, если существует потребление хранилища резервных копий.

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

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

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

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

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

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

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

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

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

Соответствие

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

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

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

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

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

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

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

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

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

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