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

  • Статья

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

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

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

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

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

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

Примечание.

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

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

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

Несколько примеров политик 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
2018-04-04 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 2028-05-13
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 управляется База данных SQL Azure. У вас нет возможности вручную создать резервную копию для долгосрочного хранения или повлиять на выбор времени ее создания. После настройки политики LTR может потребоваться до 7 дней, прежде чем первая резервная копия LTR будет отображаться в списке доступных резервных копий.

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

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

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

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

Примечание.

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

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

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

Дополнительные сведения о настройке долгосрочного хранения или восстановлении базы данных из резервной копии для Базы данных SQL с помощью портала Azure или PowerShell см. в статье Управление долгосрочным хранением резервных копий для Базы данных SQL Azure.

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

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

Примечание.

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

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

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

Ознакомьтесь с руководством по настройке резервных копий LTR и управлению ими.