Автоматическое резервное копирование для баз данных гипермасштабирования

  • Статья

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

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

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

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

Производительность резервного копирования и восстановления

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

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

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

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

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

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

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

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

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

Кратковременное хранение резервных копий в диапазоне от 1 до 35 дней и долгосрочное хранение резервных копий (LTR) для баз данных гипермасштабирования общедоступен по состоянию на сентябрь 2023 года. Дополнительные сведения см. в статье о долгосрочном хранении База данных SQL Azure и Управляемый экземпляр SQL Azure.

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

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

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

Мониторинг потребления хранилища резервных копий

В гипермасштабировании метрики Azure Monitor сообщают следующие сведения о потреблении:

  • Размер хранилища резервных копий данных (размер резервного копирования моментальных снимков)
  • Размер хранилища данных (выделенный размер базы данных)
  • Размер хранилища резервных копий журналов (размер резервного копирования журнала транзакций)

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

  1. Перейдите в базу данных Гипермасштабирования, для которой требуется отслеживать метрики резервного копирования и хранилища данных.
  2. В разделе "Мониторинг" выберите страницу метрик.
  3. В раскрывающемся списке метрик выберите хранилище резервных копий данных, размер хранилища данных и метрики хранилища резервных копий журналов с соответствующим правилом агрегирования.

Screenshot of the Azure portal that shows selections for viewing Hyperscale backup storage consumption.

Уменьшение потребления хранилища резервных копий

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

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

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

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

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

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

Total billable backup storage size = (data backup storage size + log backup storage size)

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

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

Total billable backup storage size for deleted Hyperscale database = (data storage size + data backup size + log backup storage size) * (remaining backup retention period after deletion / configured backup retention period)

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

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

Мониторинг затрат на резервное копирование

Чтобы понять затраты на хранилище резервных копий:

  1. На портале Azure перейдите в раздел Управление затратами и выставление счетов.

  2. Выберите Управление затратами>Анализ затрат.

  3. Для области выберите нужную подписку.

  4. Отфильтруйте период времени и интересующую вас службу, выполнив следующие действия:

    1. Добавьте фильтр для строки Имя службы.
    2. Выберите базу данных SQL из раскрывающегося списка.
    3. Добавьте другой фильтр для измерения.
    4. Чтобы отслеживать затраты на резервное копирование для восстановления на определенный момент времени, в раскрывающемся списке выберите хранимые данные — резервное копирование — RA .

На следующем снимка экрана показан пример анализа затрат.

Screenshot of the Azure portal that shows Hyperscale Backup storage costs.

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

Гипермасштабирование поддерживает настраиваемую избыточность хранилища. При создании базы данных гипермасштабирования можно выбрать предпочитаемый тип хранилища: геоизбыточное хранилище с доступом для чтения (RA-GZRS), геоизбыточное хранилище для чтения (RA-GRS), хранилище, избыточное между зонами (ZRS) или локально избыточное хранилище (LRS).

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

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

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

Примечание.

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

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

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

Восстановление базы данных гипермасштабирования в другом регионе

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

  1. Создайте сервер в целевом регионе, если у вас еще нет соответствующего сервера. Этот сервер должен принадлежать той же подписке, что и оригинальный (исходный) сервер.
  2. Следуйте инструкциям в разделе о геовосстановлении на странице, посвященной восстановлению базы данных из Базы данных SQL Azure с помощью автоматических резервных копий.

Примечание.

Так как исходный и целевой объект находятся в отдельных регионах, база данных не может совместно использовать хранилище моментальных снимков с исходной базой данных, так как она выполняется в негеорегационных восстановлениях. Не геовосстановление быстро завершается независимо от размера базы данных.

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

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

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

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

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