Восстановление базы данных из резервной копии в Управляемый экземпляр SQL Azure
Область применения: Управляемый экземпляр SQL Azure
В этой статье приведены шаги по восстановлению базы данных из резервной копии в Управляемый экземпляр SQL Azure. Сведения о База данных SQL Azure см. в разделе "Восстановление базы данных из резервной копии" в База данных SQL Azure.
Обзор
Автоматические резервные копии баз данных помогают защитить базы данных от ошибок пользователей и приложений, случайного удаления базы данных и длительных сбоев. Эта встроенная возможность доступна для всех уровней служб и объемов вычислительных ресурсов. Следующие параметры доступны для восстановления базы данных с помощью автоматических резервных копий:
- Создайте базу данных в одном управляемом экземпляре, восстановленную до указанной точки во времени в течение периода хранения.
- Создайте базу данных на одном управляемом экземпляре или другом управляемом экземпляре, восстановленную до указанной точки во времени в течение периода хранения.
- Создайте базу данных на одном управляемом экземпляре или другом управляемом экземпляре, восстановленную до времени удаления для удаленной базы данных.
- Создайте базу данных на любом управляемом экземпляре в одной подписке или другой подписке в одном клиенте и в одном регионе, восстановленной до точки последних резервных копий.
Если вы настроили долгосрочное хранение (LTR), вы также можете создать новую базу данных из любой долгосрочной резервной копии на любом экземпляре.
Внимание
При восстановлении существующую базу данных невозможно перезаписать.
Время восстановления
Некоторые факторы влияют на время восстановления базы данных с помощью автоматических резервных копий базы данных:
- размер базы данных;
- объем вычислительных ресурсов базы данных;
- число участвующих журналов транзакций;
- объем операций, которые требуется воспроизвести для восстановления до точки восстановления;
- пропускная способность сети, если выполняется восстановление в другой регион;
- Число одновременных запросов на восстановление, обрабатываемых в целевом регионе
Восстановление большой или очень активной базы данных может занять несколько часов. Длительный сбой в регионе может привести к большому количеству запросов геовосстановки для аварийного восстановления. При большом числе запросов время восстановления отдельных баз данных может увеличиться. В большинстве случаев на восстановление базы данных требуется менее 12 часов.
Совет
Для Управляемый экземпляр SQL Azure обновления системы имеют приоритет над восстановлением базы данных. При наличии обновления системы для Управляемого экземпляра SQL все ожидающие операции восстановления приостанавливаются, а затем возобновляются после обновления. Это может увеличить время восстановления и заметно сказаться при длительных операциях восстановления.
Чтобы достичь прогнозируемого времени восстановления базы данных, вы можете настроить периоды обслуживания, которые позволяют запланировать обновления системы на определенный день или время. Это восстановление нужно назначить так, чтобы оно не совпадало с запланированным периодом обслуживания.
Разрешения
Для восстановления с помощью автоматических резервных копий необходимо выполнить следующие действия.
- Участник SQL Server или роль участника Управляемый экземпляр SQL (в зависимости от назначения восстановления) в подписке
- Владелец подписки
Дополнительные сведения см. в статье Azure RBAC: встроенные роли.
Выполнить восстановление можно с помощью портала Azure, PowerShell или REST API. Использовать для этого Transact-SQL невозможно.
Восстановление на определенный момент времени
Восстановление до точки во времени позволяет восстановить базу данных до ранней точки во времени. Запрос может указывать любой уровень служб или объем вычислительных ресурсов для восстановленной базы данных. Убедитесь, что у вас достаточно ресурсов на экземпляре, на котором выполняется восстановление базы данных.
После завершения восстановления создается новая база данных в целевом экземпляре, будь то один и тот же экземпляр или другой экземпляр. Использование восстановленной базы данных оплачивается по обычным тарифам на основе уровня служб и объема вычислительных ресурсов. Плата не взимается до завершения восстановления базы данных.
Обычно база данных восстанавливается до более ранней точки во времени. Восстановленную базу данных можно рассматривать как замену исходной базы данных или же использовать как источник данных для обновления исходной базы данных.
Внимание
Невозможно выполнить восстановление до точки во времени базы данных-получателя с георепликацией. Это можно сделать только для базы данных-источника.
Замена базы данных
Если вы хотите, чтобы восстановленная база данных была заменой исходной базы данных, необходимо указать размер вычислительных ресурсов исходной базы данных и уровень служб. Можно переименовать исходную базу данных, а затем присвоить восстановленной базе данных исходное имя с помощью команды ALTER DATABASE в T-SQL.
Восстановление данных
Если вы планируете получить данные из восстановленной базы данных для восстановления после ошибки пользователя или приложения, необходимо написать и запустить скрипт восстановления данных, который извлекает данные из восстановленной базы данных и применяется к исходной базе данных. Хотя операция восстановления может занять много времени, восстановление базы данных отображается в списке баз данных на протяжении всего процесса восстановления.
При удалении базы данных во время восстановления операция восстановления будет отменена. Плата за базу данных, которая не завершила восстановление, не будет взиматься.
Чтобы восстановить базу данных в Управляемый экземпляр SQL до точки во времени с помощью портал Azure, можно перейти в базу данных на портале и выбрать команду "Восстановить". Кроме того, можно открыть страницу обзора целевого Управляемый экземпляр SQL и выбрать +Создать базу данных на панели инструментов, чтобы открыть страницу "Создание управляемой базы данных SQL Azure".
Укажите сведения о целевом управляемом экземпляре на вкладке "Основные сведения" и выберите тип резервного копирования на вкладке источника данных.
Дополнительные сведения см. в статье о восстановлении точки во времени.
Восстановление удаленной базы данных
Вы можете восстановить удаленную базу данных до времени удаления или более ранней точки во времени, в том же экземпляре или в другом экземпляре, отличном от исходного экземпляра. Целевой экземпляр может быть в той же подписке, что и исходный экземпляр, или в какой-либо другой подписке. Чтобы восстановить удаленную базу данных, следует создать новую базу данных из резервной копии.
Внимание
Удаленный управляемый экземпляр невозможно восстановить. При удалении управляемого экземпляра все его базы данных также удаляются и не могут быть восстановлены до состояния на момент удаления или более ранний момент времени. Если вы настроили долгосрочное хранение (LTR), вы по-прежнему можете восстановить базу данных из удаленного экземпляра в другой экземпляр и на момент времени создания резервного копирования LTR.
Чтобы восстановить базу данных с помощью портал Azure, откройте страницу обзора управляемого экземпляра и выберите "Резервные копии". Выберите, чтобы отобразить удаленные резервные копии, а затем нажмите кнопку "Восстановить рядом с удаленной резервной копией", которую вы хотите восстановить, чтобы открыть страницу "Создание управляемой базы данных SQL Azure". Укажите сведения о целевом управляемом экземпляре на вкладке "Основные сведения" и сведения о исходном управляемом экземпляре на вкладке "Источник данных". Настройте параметры хранения на вкладке "Дополнительные параметры ".
Совет
Может потребоваться несколько минут, чтобы недавно удаленные базы данных отображались на странице "Удаленные базы данных" в портал Azure или при необходимости отображать удаленные базы данных с помощью командной строки.
Геовосстановление
Внимание
- Геовосстановление доступно только для управляемых экземпляров, настроенных с геоизбыточным хранилищем резервных копий. Если в настоящее время вы не используете резервные копии с георепликацией для базы данных, вы можете настроить избыточность хранилища резервных копий.
- Геовосстановление можно выполнять только в управляемых экземплярах, которые находятся только в одной подписке.
Геовосстановление используется по умолчанию, когда база данных недоступна из-за инцидента в регионе, в котором она размещена. Базу данных можно восстановить в экземпляре в любом другом регионе. Базу данных можно восстановить в любом управляемом экземпляре в любом регионе Azure из последних геореплицированных резервных копий. При геовосстановлении в качестве источника используется геореплицированная резервная копия. Вы можете запросить геовосстановление, даже если сбой сделал базу данных или центр обработки данных недоступным.
Между созданием резервной копии и ее георепликацией в BLOB-объект Azure в другом регионе существует задержка. В результате восстановленная база данных может представлять собой исходную базу данных в состоянии, в котором она находилась в течение часа до сбоя. На следующем рисунке показано восстановление базы данных из последней доступной резервной копии в другом регионе.
В портал Azure можно восстановить геореплицированную резервную копию в существующий экземпляр или создать управляемый экземпляр и выбрать доступную резервную копию геовосстановление. Созданная база данных будет содержать геовосстановленные данные резервной копии.
Чтобы восстановить существующий экземпляр, выполните действия, описанные в разделе "Восстановление на определенный момент времени", и обязательно выберите соответствующий источник и целевые экземпляры для восстановления базы данных в целевом экземпляре.
Чтобы геовосстановление в новый экземпляр с помощью портал Azure, выполните следующие действия:
- Перейдите к новому управляемому экземпляру SQL Azure.
- Выберите Новая база данных.
- Введите имя базы данных.
- В разделе "Источник данных" выберите соответствующий тип резервной копии, а затем укажите сведения о источнике данных.
- Выберите резервную копию из списка доступных резервных копий геовосстановления.
После завершения процесса создания базы данных экземпляра она будет содержать восстановленную резервную копию геовосстановление.
Рекомендации по геовосстановлению
Геовосстановление — это самое базовое решение для аварийного восстановления, доступное в Управляемый экземпляр SQL Azure. Он использует автоматически созданные геореплицированные резервные копии в дополнительном (парном) регионе. Ниже приведены некоторые рекомендации по геовосстановлением.
- Цель точки восстановления (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 динамических административных представлений.
- Если политики конечных точек службы присутствуют в подсети, делегированной Управляемый экземпляр SQL Azure, восстановление на определенный момент времени (PITR) управляемым экземплярам в этой подсети невозможно выполнить из экземпляров в разных регионах.
- Цель точки восстановления (RPO) составляет до 1 часа.
- Цель времени восстановления (RTO) составляет около 12 часов, но может отличаться в зависимости от размера базы данных и активности может выйти за рамки этого периода времени.
- Не удается изменить дополнительный (парный) регион.
- Только что созданные и восстановленные базы данных могут не сразу отображаться как восстанавливаемые в других регионах из-за задержки в заполнении новых данных. Для создания видимых резервных копий новой базы данных может потребоваться до 24 часов.
- Максимальное количество баз данных, которые можно восстановить параллельно, составляет 200 на одну подписку. В некоторых случаях это ограничение можно увеличить, открыв запрос в службу поддержки.
- Резервные копии базы данных, полученные из экземпляров, настроенных с помощью политики обновления SQL Server 2022, можно восстановить в экземплярах, настроенных с помощью политики обновления SQL Server 2022 или Always-up-up. Резервные копии базы данных, полученные из экземпляров, настроенных с помощью политики обновления Always-up-up, можно восстановить только в экземплярах, которые также настроены с помощью политики обновления Always-up-up.
Связанный контент
- автоматическое резервное копирование Управляемый экземпляр SQL
- Длительное хранение
- Сведения о более быстрых вариантах восстановления см. в разделе "Группы отработки отказа".