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

  • Статья

Применимо к:База данных SQL Azure

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

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

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

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

Внимание

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

При использовании уровня служб "Стандартный" или "Премиум" в модели приобретения DTU восстановление базы данных может привести к дополнительным затратам на хранение. Дополнительная стоимость происходит, если максимальный размер восстановленной базы данных превышает объем хранилища, включенный в целевой уровень службы и цель службы целевой базы данных.

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

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

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

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

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

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

Вариант развертывания Максимальное количество одновременно обрабатываемых запросов Максимальное количество одновременно отправляемых запросов
Отдельная база данных (на подписку) 30 100
Эластичный пул (на пул) 4 2 000

Разрешения

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

  • Участник роли участника или роль участника SQL Server в подписке или группе ресурсов, содержащей логический сервер.
  • Владелец подписки или группы ресурсов

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

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

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

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

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

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

Внимание

  • Восстановление базы данных на том же сервере можно выполнить на определенный момент времени. Межсерверное, кросс-подписка и восстановление между точками во времени в настоящее время не поддерживается. Чтобы восстановить базу данных в другом регионе с помощью гео-реплика резервных копий, см. раздел "Геовосстановление".
  • Невозможно выполнить восстановление до точки во времени базы данных-получателя с георепликацией. Это можно сделать только для базы данных-источника.
  • Параметр BackupFrequency не поддерживается для баз данных гипермасштабирования.
  • Операции восстановления базы данных являются ресурсоемкими и могут потребовать уровня служб S3 или более поздней для восстановления (целевой) базы данных. После завершения восстановления база данных или эластичного пула может быть уменьшена при необходимости.

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

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

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

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

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

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

Снимок экрана с параметрами восстановления Базы данных SQL.

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

Для выполнения операции восстановления в долгосрочной резервной копии можно использовать портал Azure, Azure CLI, Azure PowerShell или REST API. Дополнительные сведения см. в разделе "Восстановление долгосрочного резервного копирования".

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

Снимок экрана: портал Azure с доступными долгосрочными резервными копиями хранения.

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

Вы можете восстановить удаленную базу данных до времени удаления или более ранний момент времени на том же сервере с помощью портал Azure, Azure CLI, Azure PowerShell и REST API.

Внимание

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

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

Снимок экрана: портал Azure, в котором показано, как восстановить удаленную базу данных.

Совет

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

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

Для восстановления удаленной базы данных можно использовать геовосстановление с помощью портал Azure, Azure CLI, Azure PowerShell и REST API.

Внимание

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

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

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

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

Иллюстрация геовосстановление.

В портал Azure создается отдельная база данных и выбирается доступная резервная копия геовосстановление. Созданная база данных будет содержать геовосстановленные данные резервной копии.

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

  1. На панели мониторинга выберите Добавить>Создать базу данных SQL. На вкладке Базовые введите необходимые данные.
  2. Выберите Дополнительные параметры.
  3. Для параметра Использовать существующие данные выберите значение Резервная копия.
  4. Выберите резервную копию из списка доступных резервных копий геовосстановления.

Снимок экрана: портал Azure с параметрами создания базы данных.

Выполните процесс создания базы данных из резервной копии. После создания базы данных в Базе данных SQL Azure она будет содержать восстановленную резервную копию для геовосстановления.

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

Дополнительные сведения об использовании геовосстановление см. в статье "Восстановление с помощью геовосстановки".

Примечание.

Подробные сведения о восстановлении после сбоя см. в База данных SQL Azure руководстве по аварийному восстановлению и База данных SQL Azure высокой доступности и проверка списке проверка аварийного восстановления.

Геовосстановление — это самое базовое решение для аварийного восстановления, доступное в База данных SQL. Он использует автоматически созданные гео-реплика резервные копии с целью точки восстановления (RPO) до 1 часа и предполагаемой цели времени восстановления (RTO) до 12 часов. Это не гарантирует, что в целевом регионе будет достаточно емкости для восстановления баз данных после регионального сбоя, так как объем запросов, скорее всего, резко возрастет. Если приложение использует относительно небольшие базы данных и не является критически важным для бизнеса, геовосстановление является соответствующим решением для аварийного восстановления.

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

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

Примечание.

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

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