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

Резервное копирование SQL Server по URL-адресу для Хранилища BLOB-объектов Microsoft Azure

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

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

Подсказка

Предварительная версия SQL Server 2025 (17.x) вводит резервное копирование по URL-адресу с управляемым удостоверением. Просмотрите создание резервной копии на URL-адрес с использованием управляемой идентификации (режим предварительной версии) — SQL Server, поддерживаемый Azure Arc.

Обзор

В SQL Server 2012 с пакетом обновления 1 (CU2) и SQL Server 2014 появилась возможность резервного копирования на URL-адрес, указывающий на Хранилище BLOB-объектов Azure, используя знакомый синтаксис T-SQL для безопасной записи резервных копий в хранилище Azure. SQL Server 2016 (13.x) представил File-Snapshot резервные копии для файлов базы данных в Azure и безопасность с помощью ключей SAS, безопасный и простой способ проверки подлинности сертификатов в политике безопасности службы хранилища Azure.

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

Первый этап этого процесса — создание учетной записи хранения Azure в подписке Azure. Эта учетная запись хранения является административной учетной записью, имеющей полные административные разрешения на все контейнеры и объекты, созданные с помощью этой учетной записи хранения. Для проверки подлинности, а также записи и чтения BLOB-объектов в Хранилище BLOB-объектов Azure SQL Server может использовать либо имя учетной записи хранения Azure и значение ее ключа доступа, либо маркер подписанного URL-адреса, созданный в определенных контейнерах и предоставляющий права на чтение и запись. Дополнительные сведения об учетных записях хранения Azure см. в разделе Об учетных записях хранения Azure , а дополнительные сведения о подписанных URL-адресах (SAS) см. в статье Подписанные URL-адреса. Часть 1. Общие сведения о модели SAS. Учетные данные SQL Server не только хранят эти сведения для проверки подлинности, но и используют их во время операций резервного копирования или восстановления.

Служба хранилища Azure и хранилище, совместимое с S3

SQL Server 2022 (16.x) представляет возможность записи резервных копий в хранилище объектов, совместимого с S3, с функциональностью резервного копирования и восстановления, концептуально похожей на работу с резервной копией на URL-адрес, используя Хранилище BLOB-объектов Azure в качестве типа устройства резервного копирования. SQL Server 2022 (16.x) расширяет синтаксис URL-адреса BACKUP/RESTORE TO/FROM, добавив поддержку нового соединителя S3 с помощью REST API.

В этой статье приводятся сведения об использовании резервного копирования по URL-адресу Хранилища BLOB-объектов Azure. Дополнительные сведения о резервном копировании в URL-адрес для хранилища, совместимого с S3, см. в статье Резервное копирование в URL для хранилища объектов SQL Server, совместимых с S3.

Резервное копирование в блочный и страничный BLOB-объекты службы хранилища Azure

Существует два типа BLOB-объектов, которые можно хранить в Хранилище BLOB-объектов Microsoft Azure: блочные и страничные BLOB-объекты. Для SQL Server 2016 и более поздних версий рекомендуется использовать блочный BLOB-объект.

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

Резервное копирование в блочный BLOB-объект Хранилища BLOB-объектов Azure доступно только в SQL Server 2016 или более поздней версии. Делайте резервное копирование на двоичный объект блоков вместо страничного двоичного объекта, если вы работаете с SQL Server 2016 и более поздними версиями.

Основные причины:

  • по сравнению с ключом к хранилищу, подписанный URL-адрес — это более безопасный способ для авторизации доступа к большому двоичному объекту;
  • Вы можете создать резервную копию до нескольких блочных BLOB-объектов, чтобы повысить производительность резервного копирования и восстановления, а также обеспечить более крупную резервную копию базы данных.
  • блочный BLOB-объект дешевле, чем страничный BLOB-объект.
  • Клиентам, которым необходимо выполнить копирование данных на блобы страниц через прокси-сервер, следует использовать backuptourl.exe.

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

Если база данных слишком велика, следует:

  • использовать сжатие резервной копии или
  • Резервное копирование в несколько блочных BLOB-объектов

Поддержка в Linux, контейнерах и Управляемый экземпляр SQL включена Azure Arc

Предположим, экземпляр SQL Server размещен в Linux, включая:

  • автономную операционную систему;
  • Контейнеры
  • Управляемый экземпляр SQL включен Azure Arc
  • любую другую среду на основе Linux.

Единственное поддерживаемое резервное копирование по URL-адресу — это резервное копирование в блочные BLOB-объекты с помощью подписанного URL-адреса.

Хранилище BLOB-объектов Microsoft Azure

Учетная запись хранения. Учетная запись хранения является отправной точкой для всех служб хранилища. Для доступа к Хранилищу BLOB-объектов Azure необходимо сначала создать учетную запись хранения Azure. Дополнительные сведения см. в разделе Создание учетной записи хранения.

Контейнер. Контейнер обеспечивает группирование набора больших двоичных объектов и может хранить их неограниченное количество. Для записи резервной копии SQL Server в Хранилище BLOB-объектов Azure необходимо создать по крайней мере корневой контейнер. Вы можете создать токен SAS в контейнере и предоставить доступ к объектам только в определенном контейнере.

Большой двоичный объект. Файл любого типа и размера. Существует два типа BLOB-объектов, которые могут храниться в хранилище Azure: блочные и страничные BLOB-объекты. Резервное копирование SQL Server может использовать любой тип BLOB-объектов в зависимости от используемого синтаксиса Transact-SQL. Обращаться к BLOB-объектам можно с помощью URL-адреса следующего вида: https://<учетная запись хранения>.blob.core.windows.net/<контейнер>/<BLOB-объект>. Дополнительные сведения о Хранилище BLOB-объектов Azure см. в разделе Общие сведения о Хранилище BLOB-объектов Azure. Дополнительные сведения о больших двоичных объектах см. в разделе Основные сведения о блочных и страничных больших двоичных объектах.
Схема хранилищ Blob Azure, контейнеров и blob.

Моментальный снимок Azure. Снимок большого двоичного объекта Azure, сделанный в определенный момент времени. Дополнительные сведения см. в разделе Создание моментального снимка большого двоичного объекта. Резервное копирование SQL Server теперь поддерживает резервные копии моментальных снимков Azure файлов базы данных, хранящиеся в Хранилище BLOB-объектов Azure. Дополнительные сведения см. в разделе Резервные копии моментальных снимков файлов для файлов базы данных в Azure.

Компоненты SQL Server

URL-адрес. URL-адрес указывает универсальный идентификатор ресурса (URI) для уникального файла резервной копии. URL-адрес используется, чтобы предоставить местоположение и имя файла резервной копии SQL Server. URL-адрес должен указывать на фактический большой двоичный объект, а не просто на контейнер. Если блоб не существует, он создается. Если указан существующий большой двоичный объект, то команда BACKUP завершится ошибкой, если только не указан параметр WITH FORMAT для перезаписи существующего файла резервной копии в этом большом двоичном объекте.

Ниже приведен пример значения URL-адреса: https://ACCOUNTNAME.blob.core.windows.net/<CONTAINER>/FILENAME.bak

Примечание.

Резервное копирование по URL-адресу с помощью HTTP не поддерживается.

Учетные данные: учетные данные SQL Server — это объект, который используется для хранения сведений о проверке подлинности, необходимых для подключения к ресурсу за пределами SQL Server. В данном случае процессы резервного копирования и восстановления SQL Server используют учетные данные для проверки подлинности в Хранилище BLOB-объектов Azure и его контейнерах и BLOB-объектах. Учетные данные хранят имя учетной записи хранения и значения ключа доступа этой учетной записи хранения или URL-адрес контейнера и его токен SAS. После создания учетных данных синтаксис инструкций BACKUP/RESTORE определяет тип большого двоичного объекта и необходимые учетные данные.

Порядок создания подписанного URL-адреса см. в примерах в разделе Создание подписанного URL-адреса далее в этой статье. Порядок создания учетных данных SQL Server см. в примерах в разделе Создание учетных данных далее в этой статье.

Дополнительные сведения об учетных данных см. в разделе "Учетные данные" (ядро СУБД).

Сведения о других примерах использования учетных данных см. в разделе Создание прокси-агента SQL Server.

Поддержка неизменяемого хранилища Azure

Предварительная версия SQL Server 2025 (17.x) предоставляет поддержку неизменяемого хранилища Azure, которое защищает от атак программ-шантажистов. Файлы, записанные в неизменяемое хранилище, не могут быть изменены или удалены, как определено неизменяемостью.

Как правило, резервные копии SQL Server создаются на двух шагах. Изначально файл резервной .bak копии создается с нулями, а затем файл обновляется с данными. Так как изменение файла в неизменяемом хранилище не допускается после записи и фиксации файла, процесс резервного копирования теперь пропускает начальный шаг, чтобы создать файл резервной копии с нулями. Вместо этого все резервное копирование создается на одном шаге при записи в блочные BLOB-объекты.

Во время предварительной версии флаг трассировки 3012 требуется для включения неизменяемой поддержки хранилища для резервного копирования по URL-адресу.

Чтобы использовать неизменяемое хранилище в SQL Server 2025 (17.x) в предварительной версии резервного копирования на URL, выполните следующие действия.

  1. Настройте неизменяемость для контейнера хранилища Azure.
  2. Включите флаг трассировки 3012 для экземпляра SQL Server, выполнив следующую команду DBCC:
    DBCC TRACEON(3012,-1).
  3. Выполните резервное копирование базы данных в контейнер хранилища Azure:
    BACKP DATABASE [<Database>] TO URL = ‘<url>’ WITH FORMAT.

Безопасность Хранилища BLOB-объектов Azure

Далее описаны вопросы безопасности и требования к резервному копированию и восстановлению с помощью Хранилища BLOB-объектов Azure.

  • При создании контейнера для Хранилища BLOB-объектов Azure рекомендуется установить для него частные права доступа. Установка закрытых прав доступа означает, что доступ получают только те пользователи и учетные записи, которые могут предоставить необходимую информацию для проверки подлинности в учетной записи Azure.

    Внимание

    SQL Server требует, чтобы имя учетной записи Azure и проверка подлинности ключа доступа или подписанный URL-адрес и маркер доступа хранились в учетных данных SQL Server. Эти сведения используются для проверки подлинности учетной записи Azure при резервном копировании или восстановлении.

    Предупреждение

    Служба хранилища Azure поддерживает отключение авторизации с общим ключом для учетной записи хранения. Если авторизация по общему ключу отключена, функция SQL Server Backup To URL не будет работать.

  • Учетная запись пользователя, применяемая для выдачи команды BACKUP или RESTORE, должна находиться в роли базы данных db_backup operator с разрешениями Alter any credential .

Ограничения резервного копирования и восстановления в Хранилище BLOB-объектов Azure

  • Максимальный поддерживаемый размер резервной копии с использованием страничного BLOB-объекта в SQL Server составляет 1 ТБ. Максимальный поддерживаемый размер резервной копии с использованием блочных BLOB-объектов составляет примерно 200 ГБ (50 000 блоков * 4 МБ MAXTRANSFERSIZE). Блочные BLOB-объекты поддерживают чередование для поддержки значительно большего размера резервных копий. Ограничение составляет не более 64 URL-адресов, что приводит к следующей формуле. 64 stripes * 50,000 blocks * 4MB maxtransfersize = 12.8 TB

    Внимание

    Хотя максимальный размер резервного копирования, поддерживаемый одним блочным BLOB-объектом, составляет 200 ГБ, можно записывать в SQL Server меньшие размеры блоков, что может привести к достижению ограничения на 50 000 блоков до передачи всей резервной копии. Чередуйте резервные копии (даже если они меньше 200 ГБ), чтобы избежать ограничения на количество блоков, особенно если используются разностные или несжатые резервные копии.

  • Инструкции резервного копирования или восстановления можно выдавать с помощью командлетов Transact-SQL, SMO, PowerShell или мастера резервного копирования или восстановления SQL Server Management Studio.

  • Резервное копирование в служба хранилища Azure учетной записи поддерживает проверку подлинности только с помощью маркеров подписанного URL-адреса (SAS) или ключей учетной записи хранения. Все остальные методы проверки подлинности, включая проверку подлинности с помощью идентификатора Microsoft Entra (ранее Azure Active Directory), не поддерживаются.

  • Создание имени логического устройства не поддерживается. Поэтому добавление URL-адреса в качестве устройства резервного копирования с помощью sp_dumpdevice или через SQL Server Management Studio не поддерживается.

  • Добавление к существующим BLOB-объектам резервного копирования не поддерживается. Резервные копии в существующий блоб можно только перезаписать с помощью WITH FORMAT опции. Однако при использовании резервных копий моментальных снимков файлов (с помощью аргумента WITH FILE_SNAPSHOT) аргумент WITH FORMAT не допускается, чтобы избежать возникновения сиротских моментальных снимков файлов, созданных с помощью исходной резервной копии моментальных снимков файлов.

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

  • Указание BLOCKSIZE не поддерживается для страничных блобов.

  • Указание MAXTRANSFERSIZE не поддерживается для страничных BLOB-объектов.

  • Указание параметров набора резервных копий — RETAINDAYS и EXPIREDATE не поддерживается.

  • SQL Server имеет максимальное ограничение в 259 символов для имени устройства резервного копирования. URL-адрес BACKUP TO использует 36 символов для необходимых элементов, используемых для указания URL-адреса https://.blob.core.windows.net//.bak, оставляя 223 символа для имени учетной записи, контейнера и имени BLOB-объекта.

  • SQL Server 2019 (15.x) и более ранние версии имеют ограничение в 256 символов для маркеров общего доступа (SAS), что ограничивает тип маркеров, которые можно использовать (например, маркеры ключа делегирования пользователя не поддерживаются).

  • Если сервер обращается к Azure через прокси-сервер, необходимо использовать флаг трассировки 1819, а затем настроить конфигурацию прокси WinHTTP одним из следующих способов.

    • Служебная программа proxycfg.exe в Windows XP, Windows Server 2003 и более ранних версиях.
    • Служебная программа netsh.exe в Windows Vista и Windows Server 2008 или более поздней версии.

  • Неизменяемое хранилище для хранилища BLOB-объектов Azure не поддерживается. Задайте для политики Неизменяемое хранилище значение false.

Поддерживаемые аргументы и утверждения в хранилище Blob Azure

Поддержка инструкций резервного копирования и восстановления в Хранилище BLOB-объектов Azure

Инструкции BACKUP и RESTORE Поддерживается Исключения Комментарии
Резервное копирование У BLOCKSIZE и MAXTRANSFERSIZE поддерживаются для блочных BLOB-объектов. Они не поддерживаются для страничных BLOB-объектов. Для резервного копирования в блочный BLOB-объект требуется сохранить подписанный URL-адрес в учетных данных SQL Server. Для резервного копирования на страницу BLOB-объекта требуется ключ учетной записи хранения, сохраненный в учетных данных SQL Server, и требуется указать аргумент WITH CREDENTIAL.
ВОССТАНОВИТЬ У Требуется определить учетные данные SQL Server и указать аргумент WITH CREDENTIAL, если учетные данные SQL Server определены с помощью ключа учетной записи хранения в качестве секрета.
Восстановление списка файлов У Требуется определить учетные данные SQL Server и указать аргумент WITH CREDENTIAL, если учетные данные SQL Server определены с помощью ключа учетной записи хранения в качестве секрета.
инструкция RESTORE HEADERONLY У Требуется определить учетные данные SQL Server и указать аргумент WITH CREDENTIAL, если учетные данные SQL Server определены с помощью ключа учетной записи хранения в качестве секрета.
ВОССТАНОВИТЬ labelonly У Требуется определить учетные данные SQL Server и указать аргумент WITH CREDENTIAL, если учетные данные SQL Server определены с помощью ключа учетной записи хранения в качестве секрета.
ВОССТАНОВИТЬ ТОЛЬКО ПРОВЕРКУ У Требуется определить учетные данные SQL Server и указать аргумент WITH CREDENTIAL, если учетные данные SQL Server определены с помощью ключа учетной записи хранения в качестве секрета.
ВОССТАНОВИТЬ REWINDONLY -

Сведения о синтаксисе и общих сведениях об инструкциях резервного копирования см. в статье BACKUP.

Сведения о синтаксисе и общих сведениях об инструкциях восстановления см. в инструкциях RESTORE.

Поддержка аргументов резервного копирования в Хранилище BLOB-объектов Azure

Аргумент Поддерживается Исключение Комментарии
База данных У
ЖУРНАЛ У
НА (URL) У В отличие от DISK и TAPE, URL-адрес не поддерживает указание или создание логического имени. Этот аргумент используется, чтобы указать URL-адрес для файла резервной копии.
К ЗЕРКАЛУ У
WITH Параметры:
УЧЁТНЫЕ ДАННЫЕ У WITH CREDENTIAL поддерживается только при использовании параметра BACKUP TO URL для резервного копирования в Хранилище BLOB-объектов Azure и только если учетные данные SQL Server определяются с использованием ключа учетной записи хранения в качестве секрета.
Снимок файла У
ШИФРОВАНИЕ У Если аргумент WITH ENCRYPTION указан, то SQL Server File-Snapshot Backup гарантирует, что вся база данных была зашифрована с помощью TDE перед выполнением резервного копирования, и если это так, то шифрует файл моментального снимка файловой резервной копии с помощью алгоритма, указанного для TDE в этой базе данных. Если все данные в базе данных во всей базе данных не шифруются, резервное копирование завершается сбоем (например, процесс шифрования еще не завершен).
DIFFERENTIAL (разностная) У
Только копирование У
СЖАТИЕ|NO_COMPRESSION У Не поддерживается для резервного копирования моментальных снимков файлов.
ОПИСАНИЕ У
ИМЯ У
ИСТЕК СРОК ДЕЙСТВИЯ | RETAINDAYS -
NOINIT | INIT - Невозможно добавлять данные к BLOB-объектам. Чтобы перезаписать резервную копию, используйте WITH FORMAT аргумент. Однако при использовании резервных копий моментальных снимков файлов (с аргументом WITH FILE_SNAPSHOT) аргумент WITH FORMAT не допускается, чтобы избежать оставления осиротевших моментальных снимков файлов, созданных с исходной резервной копией.
NOSKIP | СКИП -
NOFORMAT | ФОРМАТ У Резервное копирование, созданное для существующего BLOB, завершается ошибкой, если WITH FORMAT не указан. Существующий большой двоичный объект перезаписывается, когда указано WITH FORMAT. Однако при использовании резервных копий моментальных снимков файлов (с помощью WITH FILE_SNAPSHOT аргумента) аргумент FORMAT не допускается, чтобы избежать потерянных моментальных снимков файлов, созданных с исходной резервной копией моментального снимка файлов. Однако при использовании резервных копий моментальных снимков файлов (с аргументом WITH FILE_SNAPSHOT) аргумент WITH FORMAT не допускается, чтобы избежать оставления осиротевших моментальных снимков файлов, созданных с исходной резервной копией.
ОПИСАНИЕ МЕДИА У
MEDIANAME У
РАЗМЕР БЛОКА У Не поддерживается для страничных BLOB-объектов. Поддерживается для блочных BLOB-объектов. Для оптимизации использования 50 000 блоков, допустимых в блочном BLOB-объекте, рекомендуемый размер блока BLOCKSIZE составляет 65 536 байт.
BUFERCOUNT У
Максимальный размер передачи У Не поддерживается для страничных BLOB-объектов. Поддерживается для блочных BLOB-объектов. Значение по умолчанию составляет 1 048 576 байт. Значение может изменяться в диапазоне до 4 МБ с шагом в 65 536 байт.
Для оптимизации использования 50 000 блоков, допустимых в блочном BLOB-объекте, рекомендуемый размер функции MAXTRANSFERSIZE составляет 4 194 304 байт.
NO_CHECKSUM | КОНТРОЛЬНАЯ СУММА У
ОСТАНОВИТЬ_ПРИ_ОШИБКЕ | ПРОДОЛЖИТЬ_ПОСЛЕ_ОШИБКИ У
СТАТИСТИКА У
REWIND | NOREWIND -
ВЫГРУЗКА | NOUNLOAD -
NORECOVERY | РЕЗЕРВНЫЙ У
NO_TRUNCATE У

Дополнительные сведения о аргументах резервного копирования см. в статье BACKUP.

Поддержка аргументов восстановления в Хранилище BLOB-объектов Azure

Аргумент Поддерживается Исключения Комментарии
База данных У
ЖУРНАЛ У
ИЗ (URL) У Аргумент FROM URL используется, чтобы указать URL-адрес для файла резервной копии.
С параметрами:
УЧЁТНЫЕ ДАННЫЕ У WITH CREDENTIAL поддерживается только при использовании параметра RESTORE FROM URL для восстановления из Хранилища BLOB-объектов Azure.
ЧАСТИЧНЫЙ У
ВОССТАНОВЛЕНИЕ | NORECOVERY | РЕЗЕРВНЫЙ У
Загрузить историю У
ПЕРЕМЕСТИТЬ У
ЗАМЕНИТЬ У
ПЕРЕЗАПУСК У
Ограниченный_Пользователь У
ФАЙЛ -
ПАРОЛЬ У
MEDIANAME У
Медиапароль У
РАЗМЕР БЛОКА У
BUFERCOUNT -
Максимальный размер передачи -
КОНТРОЛЬНАЯ СУММА | NO_CHECKSUM У
ОСТАНОВИТЬ_ПРИ_ОШИБКЕ | ПРОДОЛЖИТЬ_ПОСЛЕ_ОШИБКИ У
FILESTREAM У Не поддерживается для резервного копирования моментальных снимков.
СТАТИСТИКА У
REWIND | NOREWIND -
ВЫГРУЗКА | NOUNLOAD -
сохранить репликацию У
KEEP_CDC У
ВКЛЮЧИТЬ_БРОКЕР | ОШИБКА_БРОКЕРСКИХ_РАЗГОВОРОВ | НОВЫЙ_БРОКЕР У
STOPAT | STOPATMARK | STOPBEFOREMARK У

Дополнительные сведения о аргументах восстановления см. в инструкциях RESTORE — Аргументы.

Резервное копирование с помощью SSMS

С помощью этой задачи можно выполнять резервное копирование на URL-адрес с использованием учетных данных SQL Server.

Примечание.

Чтобы создать резервную копию файловых снимков SQL Server или перезаписать существующий набор носителей, необходимо использовать Transact-SQL, PowerShell или C# вместо команды резервного копирования в SQL Server Management Studio.

Ниже приведены инструкции по внесению изменений в задачу "Резервное копирование базы данных" в SQL Server Management Studio для создания резервной копии в хранилище Azure.

  1. В обозревателе объектовподключитесь к экземпляру компонента SQL Server Database Engine и разверните его.

  2. Разверните узел Базы данных, щелкните правой кнопкой мыши нужную базу данных, наведите указатель на пункт Задачи и выберите Создать резервную копию....

  3. На странице «Общие» в разделе «Назначение» в раскрывающемся списке «Резервное копирование в:» доступен параметр URL. Параметр URL-адрес используется для создания резервной копии в хранилище Windows Azure. Нажмите кнопку "Добавить", а откроется диалоговое окно "Выбор назначения резервного копирования ":

    1. Контейнер хранилища Azure. Имя контейнера хранилища Windows Azure для хранения файлов резервной копии. Выберите существующий контейнер из раскрывающегося списка или вручную введите контейнер.

    2. Политика общего доступа: Введите подписанный URL-адрес для контейнера, введенного вручную. Это поле недоступно, если был выбран существующий контейнер.

    3. Файл резервной копии. Имя файла резервной копии.

    4. Новый контейнер: Используется для регистрации существующего контейнера, для которого у вас нет маркированного доступа. См. статью "Подключение к подписке Microsoft Azure" (URL-адрес резервного копирования).

Примечание.

Добавить поддерживает несколько файлов резервных копий и контейнеров хранилища для одного набора носителей.

При выборе URL-адреса в качестве назначения некоторые параметры на странице Параметры носителя отключаются. В следующих разделах приводятся дополнительные сведения о диалоговом окне "Резервное копирование базы данных".

Резервное копирование с помощью плана обслуживания

Как и в описанной выше задаче резервного копирования, мастер плана обслуживания в SQL Server Management Studio включает URL-адрес в качестве одного из вариантов назначения и другие вспомогательные объекты, необходимые для резервного копирования в хранилище Azure, например учетные данные SQL. Дополнительные сведения см. в разделе Определение задач резервного копирования статьи Using Maintenance Plan Wizard.

Примечание.

Чтобы создать набор резервных копий с чередующимися полосами, резервную копию моментального снимка файловых данных SQL Server или учетные данные SQL с помощью токена доступа общего пользования, необходимо использовать Transact-SQL, PowerShell или C# вместо задачи резервного копирования в секции мастера планов обслуживания.

Восстановление с помощью SSMS

При восстановлении базы данных URL-адрес включается в качестве устройства, с которого следует выполнить восстановление. Следующие шаги описывают использование задачи восстановления для восстановления из Хранилища BLOB-объектов Azure.

  1. Щелкните правой кнопкой мыши узел Базы данных и выберите команду Восстановить базу данных...

  2. На странице Общие выберите пункт Устройство в разделе Источник .

  3. Нажмите кнопку обзора (...), чтобы открыть диалоговое окно Выбор устройств резервного копирования.

  4. Выберите URL-адрес из Тип носителя резервной копии: выпадающий список. Нажмите кнопку Добавить, чтобы открыть диалоговое окно Выбор расположения файла резервной копии.

    1. Контейнер хранилища Azure: полное имя контейнера хранилища Microsoft Azure, содержащего файлы резервного копирования. Выберите существующий контейнер из раскрывающегося списка или вручную введите полное имя контейнера.

    2. Подписанный URL-адрес: Используется для ввода подписанного URL-адреса для указанного контейнера.

    3. Добавить: Используется для регистрации существующего контейнера, для которого у вас нет общей подписи доступа. См. статью "Подключение к подписке Microsoft Azure" (URL-адрес резервного копирования).

    4. ОК. SQL Server подключится к хранилищу Windows Azure с помощью предоставленных учетных данных SQL и откроет диалоговое окно Поиск файла резервной копии в Windows Azure. На этой странице отобразятся файлы резервной копии, находящиеся в контейнере хранилища. Выберите файл, который требуется использовать для восстановления, и нажмите кнопку ОК. При этом вы вернееесь в диалоговое окно "Выбор устройств резервного копирования " и нажмите кнопку "ОК " в этом диалоговом окне восстановления, где можно завершить восстановление.

Примеры кода

В этом разделе содержатся следующие примеры.

Примечание.

Руководство по использованию SQL Server 2016 с хранилищем Blob Azure см. в руководстве: Использование хранилища Blob Azure с SQL Server.

Создание подписанного URL-адреса

В следующем примере создаются подписанные URL-адреса, которые можно использовать для создания учетных данных SQL Server в только что созданном контейнере. Этот сценарий создает подписанный URL-адрес, связанный с хранимой политикой доступа. Дополнительные сведения см. в статье Подписанные URL-адреса. Часть 1. Общие сведения о модели SAS(Shared Access Signatures, Part 1: Understanding the SAS Model). Кроме того, скрипт записывает команду T-SQL, необходимую для создания учетных данных в SQL Server.

Примечание.

В этом примере требуется Microsoft Azure PowerShell. Сведения об установке и использовании Azure PowerShell см. в статье "Установка и настройка Azure PowerShell".
Эти скрипты были проверены с помощью Azure PowerShell 5.1.15063.

Подписанный URL-адрес, связанный с хранимой политикой доступа

# Define global variables for the script
$prefixName = '<a prefix name>'  # used as the prefix for the name for various objects
$subscriptionName='<your subscription name>'   # the name of subscription name you will use
$locationName = '<a data center location>'  # the data center region you will use
$storageAccountName= $prefixName + 'storage' # the storage account name you will create or use
$containerName= $prefixName + 'container'  # the storage container name to which you will attach the SAS policy with its SAS token
$policyName = $prefixName + 'policy' # the name of the SAS policy

# Set a variable for the name of the resource group you will create or use
$resourceGroupName=$prefixName + 'rg'

# adds an authenticated Azure account for use in the session
Connect-AzAccount

# set the tenant, subscription and environment for use in the rest of
Set-AzContext -SubscriptionName $subscriptionName

# create a new resource group - comment out this line to use an existing resource group
New-AzResourceGroup -Name $resourceGroupName -Location $locationName

# Create a new ARM storage account - comment out this line to use an existing ARM storage account
New-AzStorageAccount -Name $storageAccountName -ResourceGroupName $resourceGroupName -Type Standard_RAGRS -Location $locationName

# Get the access keys for the ARM storage account
$accountKeys = Get-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName

# Create a new storage account context using an ARM storage account
$storageContext = New-AzStorageContext -StorageAccountName $storageAccountName -StorageAccountKey $accountKeys[0].value

# Creates a new container in Azure Blob Storage
$container = New-AzStorageContainer -Context $storageContext -Name $containerName
$cbc = $container.CloudBlobContainer

# Sets up a Stored Access Policy and a Shared Access Signature for the new container
$policy = New-AzStorageContainerStoredAccessPolicy -Container $containerName -Policy $policyName -Context $storageContext -ExpiryTime $(Get-Date).ToUniversalTime().AddYears(10) -Permission "rwld"
$sas = New-AzStorageContainerSASToken -Policy $policyName -Context $storageContext -Container $containerName
Write-Host 'Shared Access Signature= '$($sas.TrimStart('?'))''

# Outputs the Transact SQL to the clipboard and to the screen to create the credential using the Shared Access Signature
Write-Host 'Credential T-SQL'
$tSql = "CREATE CREDENTIAL [{0}] WITH IDENTITY='Shared Access Signature', SECRET='{1}'" -f $cbc.Uri,$sas.TrimStart('?')
$tSql | clip
Write-Host $tSql

После успешного выполнения скрипта скопируйте CREATE CREDENTIAL команду в средство запроса, подключитесь к экземпляру SQL Server и выполните команду, чтобы создать учетные данные с подписанным URL-адресом.

Создание учетных данных

В следующих примерах создаются учетные данные SQL Server для проверки подлинности в Хранилище BLOB-объектов Azure. Выполните одно из следующих действий.

  1. Использование подписанного URL-адреса

    Если вы выполнили предыдущий сценарий для создания подписанного URL-адреса, скопируйте CREATE CREDENTIAL его в редактор запросов, подключенный к экземпляру SQL Server, и выполните команду.

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

    IF NOT EXISTS (SELECT *
               FROM sys.credentials
               WHERE name = 'https://<mystorageaccountname>.blob.core.windows.net/<mystorageaccountcontainername>')
    CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<mystorageaccountcontainername>]
        WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET = '<SAS_TOKEN>';

  2. Использование удостоверения учетной записи хранения и ключа доступа

    IF NOT EXISTS (SELECT *
               FROM sys.credentials
               WHERE name = '<mycredentialname>')
    CREATE CREDENTIAL [<mycredentialname>]
        WITH IDENTITY = '<mystorageaccountname>', SECRET = '<mystorageaccountaccesskey>';

Выполнение полного резервного копирования базы данных

В следующих примерах выполняется полная резервная копия AdventureWorks2022 базы данных для Хранилище BLOB-объектов Azure. Используйте один из следующих примеров:

  1. На URL-адрес с использованием подписанного URL-адреса

    BACKUP DATABASE AdventureWorks2022
    TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak';
GO

  2. На URL-адрес с использованием удостоверения учетной записи хранения и ключа доступа

    BACKUP DATABASE AdventureWorks2022
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak'
WITH CREDENTIAL = '<mycredentialname>',
COMPRESSION, STATS = 5;
GO

Восстановление до точки во времени с помощью STOPAT

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

С URL-адреса с использованием подписанного URL-адреса

RESTORE DATABASE AdventureWorks2022 FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022_2015_05_18_16_00_00.bak'
WITH
MOVE 'AdventureWorks2022_data' TO 'C:\Program Files\Microsoft SQL Server\<myinstancename>\MSSQL\DATA\AdventureWorks2022.mdf',
MOVE 'AdventureWorks2022_log' TO 'C:\Program Files\Microsoft SQL Server\<myinstancename>\MSSQL\DATA\AdventureWorks2022.ldf',
NORECOVERY, REPLACE, STATS = 5;
GO

RESTORE LOG AdventureWorks2022 FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022_2015_05_18_18_00_00.trn'
WITH RECOVERY, STOPAT = 'May 18, 2015 5:35 PM';
GO

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