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

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

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

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

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

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

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

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

Примечание.

Сейчас невозможно настроить резервные копии База данных SQL Azure и Управляемый экземпляр SQL Azure как неизменяемые. Резервные копии LTR не изменяются, но их можно удалить с помощью портала Azure, Azure CLI, PowerShell или REST API.

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

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

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

Примечание.

В Azure SQL Database и Azure SQL Managed Instance при первоначальном включении политики 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) можно выполнить, выбрав необходимую резервную копию по метке времени. Базу данных можно восстановить на любой доступный сервер или в любой управляемый экземпляр с той же подпиской, что и у исходной базы данных.

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

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

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

Подсказка

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

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

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

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

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

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