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

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

  • Статья

Область применения: Управляемый экземпляр SQL Azure

В этой статье описаны шаги по восстановлению базы данных из резервной копии в Azure SQL Managed Instance. Для базы данных Azure SQL см. раздел "Восстановление базы данных из резервной копии в Azure SQL Database".

Обзор

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

  • Создайте новую базу данных на том же управляемом экземпляре, восстановленную до указанной точки во времени в течение периода хранения данных.
  • Создайте базу данных на одном управляемом экземпляре или другом управляемом экземпляре, восстановленную до указанной точки во времени в течение периода хранения.
  • Создайте базу данных на одном управляемом экземпляре или другом управляемом экземпляре, восстановленную до времени удаления для удаленной базы данных.
  • Создайте новую базу данных на любом управляемом экземпляре в той же подписке или другой подписке в одном клиенте и в одном регионе, восстановив её до состояния на момент последних резервных копий.

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

Внимание

При восстановлении существующую базу данных невозможно перезаписать.

Время восстановления

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

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

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

Совет

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

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

Разрешения

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

  • Участник роли SQL Server Contributor или Управляемого экземпляра SQL Contributor (в зависимости от назначения восстановления) в подписке
  • Владелец подписки

Дополнительные сведения см. в статье Azure RBAC: встроенные роли.

Выполнить восстановление можно с помощью портала Azure, PowerShell или REST API. Использовать для этого Transact-SQL невозможно.

Восстановление на определенный момент времени

Вы можете восстановить базу данных на более раннюю дату. Запрос может указывать любой уровень служб или объем вычислительных ресурсов для восстановленной базы данных. Убедитесь, что у вас достаточно ресурсов на экземпляре, на котором выполняется восстановление базы данных.

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

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

Внимание

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

  • Замена базы данных

    Если вы хотите, чтобы восстановленная база данных была заменой исходной базы данных, необходимо указать размер вычислительных ресурсов исходной базы данных и уровень служб. Можно переименовать исходную базу данных, а затем присвоить восстановленной базе данных исходное имя с помощью команды ALTER DATABASE в T-SQL.

  • Восстановление данных

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

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

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

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

Укажите сведения о целевом управляемом экземпляре на вкладке "Основные сведения" и выберите тип резервного копирования на вкладке источника данных.

Снимок экрана: портал Azure, на котором показана вкладка источника данных на странице

Дополнительные сведения см. в статье «Восстановление точки во времени».

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

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

Чтобы восстановить базу данных с помощью портал Azure, откройте страницу обзора управляемого экземпляра и выберите "Резервные копии". Выберите, чтобы отобразить удаленные резервные копии, а затем нажмите кнопку "Восстановить рядом с удаленной резервной копией", которую вы хотите восстановить, чтобы открыть страницу "Создание управляемой базы данных SQL Azure". Укажите сведения о целевом управляемом экземпляре на вкладке "Основные сведения" и сведения о исходном управляемом экземпляре на вкладке "Источник данных". Настройте параметры хранения на вкладке "Дополнительные параметры ".

Снимок экрана страницы портала Azure, страницы

Совет

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

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

Если необходимо восстановить непреднамеренно удаленный управляемый экземпляр SQL, обратитесь в службу поддержки Майкрософт в течение 5 дней после операции удаления. Рассмотрим следующее:

  • Вам нужен существующий экземпляр с соответствующим уровнем служб и равным или более высоким уровнем SLO в качестве удаленного экземпляра. Будьте готовы оказать поддержку, предоставив подробные сведения о целевом экземпляре.
  • Зашифрованные базы данных, защищенные ключом, управляемым клиентом (CMK), можно восстановить только в экземплярах, имеющих доступ к одному ключу.
  • Можно восстановить только созданные пользователем базы данных. Системные базы данных не могут быть восстановлены.
  • Восстановление возможно только до последней точечной резервной копии, выполненной непосредственно перед удалением экземпляра, используя финальную резервную копию хвостового журнала перед операцией удаления.

Геовосстановление

Внимание

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

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

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

Иллюстрация восстановления базы данных в разных регионах для геовосстановления.

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

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

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

  1. Перейдите к новому управляемому экземпляру SQL Azure.
  2. Выберите Новая база данных.
  3. Введите имя базы данных.
  4. В разделе "Источник данных" выберите соответствующий тип резервной копии, а затем укажите сведения о источнике данных.
  5. Выберите резервную копию из списка доступных резервных копий геовосстановления.

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

Рекомендации по восстановлению данных геолокации

Геовосстановление — это самое базовое решение для аварийного восстановления, доступное в управляемом экземпляре Azure SQL. Он использует автоматически созданные геореплицированные резервные копии в дополнительном (парном) регионе. Вот некоторые соображения по геовосстановлению.

  • Цель точки восстановления (RPO) — до 1 часа.
  • Процессы восстановления (время восстановления — RTO) обычно занимают менее 12 часов, но могут варьироваться в зависимости от размера базы данных и активности, поэтому восстановление может длиться дольше этого временного интервала.
  • Дополнительный (парный) регион — это параметры хранилища Azure для основного региона. Вы не можете изменить дополнительный регион.
  • Только что созданные и восстановленные базы данных могут не сразу отображаться как восстанавливаемые в других регионах из-за задержки в заполнении новых данных. Если клиенты не видят резервные копии новых баз данных, они должны ожидать период ожидания до 24 часов.

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

Дополнительные сведения о непрерывности бизнес-процессов см. в обзоре обеспечения непрерывности бизнес-процессов.

Ограничения

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

  • Геовосстановление базы данных может выполняться только на экземпляре в той же подписке, что и исходный управляемый экземпляр SQL.
  • Базы данных в управляемом экземпляре SQL Azure по умолчанию шифруются с помощью TDE. Если исходная база данных использует управляемый клиентом ключ (CMK) в качестве средства защиты TDE, для восстановления базы данных в экземпляре, отличном от исходного Управляемый экземпляр SQL, целевой экземпляр должен иметь доступ к тому же ключу, который используется для шифрования исходной базы данных в Azure Key Vault, или необходимо отключить шифрование TDE в исходной базе данных перед созданием резервного копирования.
  • Ход выполнения процесса восстановления можно отслеживать только с помощью sys.dm_exec_requests и sys.dm_operation_status динамических административных представлений.
  • Если политики конечных точек службы присутствуют в подсети, делегированной под Azure SQL Управляемый экземпляр, восстановление на определенный момент времени (PITR) управляемым экземплярам в этой подсети невозможно выполнить из экземпляров в разных регионах.
  • Цель точки восстановления (RPO) — до 1 часа.
  • Цель времени восстановления (RTO) составляет около 12 часов, но может отличаться в зависимости от размера базы данных и активности может выйти за рамки этого периода времени.
  • Изменение вторичного (парного) региона невозможно.
  • Только что созданные и восстановленные базы данных могут не сразу отображаться как восстанавливаемые в других регионах из-за задержки в заполнении новых данных. Для создания видимых резервных копий новой базы данных может потребоваться до 24 часов.
  • Максимальное количество баз данных, которые можно восстановить параллельно, составляет 200 на одну подписку. В некоторых случаях это ограничение можно увеличить, открыв запрос в службу поддержки.
  • Резервные копии базы данных, полученные из экземпляров, настроенных с использованием политики обновления SQL Server 2022, можно восстановить в экземплярах, настроенных с использованием политики обновления SQL Server 2022 или Always-up-to-date. Резервные копии базы данных, полученные из экземпляров, настроенных с помощью политики обновления Always-up-up, можно восстановить только в экземплярах, которые также настроены с помощью политики обновления Always-up-up.

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