Поделиться через

Долгосрочные резервные копии хранения — База данных SQL Azure и Управляемый экземпляр SQL Azure

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

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

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

Как работает долгосрочное хранение

Многие приложения имеют нормативные, соответствие или другие бизнес-причины, которые требуют сохранения резервных копий базы данных за пределами 1–35 дней, предоставляемых краткосрочным периодом хранения автоматических резервных копий. Долгосрочное хранение резервных копий (LTR) зависит от полных резервных копий базы данных, которые автоматически создаются службой Azure SQL. Дополнительные сведения см. в статье Automated backups in База данных SQL Azure or Automated backups in Управляемый экземпляр SQL Azure.

С помощью функции LTR можно хранить резервные копии SQL Database и Управляемый экземпляр SQL в избыточном хранилище Azure Blob с настраиваемой политикой хранения до 10 лет. Резервные копии LTR можно восстановить в виде новой базы данных. Если политика LTR настроена, автоматические резервные копии копируются в разные блоки для долгосрочного хранения, которые можно использовать для того, чтобы восстановить базу данных до конкретного момента времени. Процесс копирования — это фоновое задание, которое не влияет на производительность рабочей нагрузки базы данных. Политика LTR для каждой базы данных также может указывать частоту создания резервных копий LTR.

Примечание.

Чтобы включить LTR, можно определить политику с помощью сочетания четырех параметров: еженедельное хранение резервных копий (W), ежемесячное хранение резервных копий (M), ежегодное хранение резервных копий (Y) и неделя года (WeekOfYear). При указании W каждую неделю резервная копия копируется в долгосрочное хранилище. При указании M первая резервная копия каждого месяца копируется в долгосрочное хранилище. При указании Y одна резервная копия в течение недели, указанной WeekOfYear, копируется в долгосрочное хранилище. Если указанный параметр WeekOfYear относится к прошлому в момент настройки политики, то первая резервная копия LTR создается в следующем году. Каждая резервная копия хранится в долгосрочном хранилище в соответствии с параметрами политики, настроенными при создании резервной копии LTR.

Изменения политики LTR применяются только к будущим резервным копиям. Например, при изменении еженедельного хранения резервных копий (W), ежемесячного хранения резервных копий (M) или ежегодного хранения резервных копий (Y) новый параметр хранения применяется только к новым резервным копиям. Хранение существующих резервных копий не изменяется. Политику LTR можно настроить для каждой базы данных в База данных SQL Azure и Управляемый экземпляр SQL Azure. Если вы планируете удалить старые резервные копии LTR до истечения срока хранения, можно вручную удалить резервные копии.

Примечание.

В обоих База данных SQL Azure и Управляемый экземпляр SQL Azure, когда вы впервые включаете политику LTR для базы данных, последнее полное резервное копирование из точки восстановления во времени (PITR) копируется в долгосрочное хранилище.

Несколько примеров политик LTR:

  • W=0, M=0, Y=5, WeekOfYear=3

    Третья полная резервная копия каждого года хранится в течение пяти лет.

  • W=0, M=3, Y=0

    Первая полная резервная копия каждого месяца хранится в течение трех месяцев.

  • W=12, M=0, Y=0

    Каждое еженедельное полное резервное копирование хранится в течение 12 недель.

  • W=6, M=12, Y=10, WeekOfYear=20

    Каждое еженедельное полное резервное копирование хранится в течение шести недель. Кроме первой полной резервной копии каждого месяца, которая хранится в течение 12 месяцев. Кроме полного резервного копирования, сделанного на 20-й неделе года, которое хранится в течение 10 лет.

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

W=12 weeks (84 дня), M=12 months (365 дней), Y=10 years (3650 дней), WeekOfYear=20 (неделя после 13 мая)

Ниже приведены даты в ISO 8601 (YYYY-MM-DD).

Резервное копирование PITR в LTR Срок действия W Срок действия M Срок действия Y
2018-03-07 2019-03-02
2018-03-14 2018-06-06
2018-03-21 2018-06-13
2018-03-28 2018-06-20
04.04.2018 2019-03-30
2018-04-11 2018-07-04
2018-04-18 2018-07-11
2018-04-25 18.07.2018
2018-05-02 2019-04-27
2018-05-09 2018-08-01
2018-05-16 13.05.2028
2018-05-23 2018-08-15
2018-05-30 2018-08-22
2018-06-06 2019-06-01
2018-06-13 2018-09-05
2018-06-20 2018-09-12
2018-06-27 2018-09-19
2018-07-04 2019-06-29
2018-07-11 2018-10-03
18.07.2018 2018-10-10
2018-07-25 2018-10-17
2018-08-01 2019-07-27
2018-08-08 2018-10-31
2018-08-15 2018-11-07
2018-08-22 2018-11-14
2018-08-29 2018-11-21

Если изменить эту политику и установить W=0 (без еженедельных резервных копий), еженедельные резервные копии сохраняются до истечения срока их действия, а затем служба сохраняет только ежемесячные и ежегодные резервные копии. Будущие еженедельные резервные копии не хранятся в политике LTR. Объем хранилища, необходимый для хранения этих резервных копий, сократится соответственно.

Внимание

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

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

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

Георепликация и долгосрочное хранение резервных копий

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

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

Настройка долгосрочного хранения резервных копий

Вы можете настроить долгосрочное хранение резервных копий с помощью портала Azure и PowerShell для База данных SQL Azure и Управляемый экземпляр SQL Azure. Восстановление базы данных из хранилища долгосрочного хранения (LTR) можно выполнить, выбрав необходимую резервную копию по метке времени. Базу данных можно восстановить на любом существующем сервере или управляемом экземпляре в той же подписке , что и исходная база данных. Полный список возможностей восстановления, ограничений и функций см. в разделе Restore и функции в Управляемый экземпляр SQL Azure.

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

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

  • Сохраняйте резервные копии дольше 10 лет.
  • Сохраняйте ежедневные копии баз данных дольше 35 дней.
  • Хранение резервных копий базы данных в неизменяемом хранилище.

Подсказка

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

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

Управление долгосрочным хранением резервных копий в База данных SQL Azure

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

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

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

  • Last updated on