Резервное копирование SQL Server по URL-адресу для Хранилища BLOB-объектов Microsoft Azure
Область применения:
SQL Server Управляемый экземпляр SQL Azure
В этой статье представлены основные понятия, требования и компоненты, необходимые для использования Хранилища BLOB-объектов Azure в качестве места назначения резервного копирования. Функции резервного копирования и восстановления аналогичны при использовании DISK и TAPE, но имеют некоторые отличия. В данной статье описываются эти различия, а также приводится несколько примеров кода.
Обзор
Важно понимать компоненты и взаимодействие между ними для выполнения резервного копирования или восстановления из Microsoft Хранилище BLOB-объектов Azure.
Первый этап этого процесса — создание учетной записи хранения Azure в подписке Azure. Эта учетная запись хранения является административной учетной записью, имеющей полные административные разрешения на все контейнеры и объекты, созданные с помощью этой учетной записи хранения. Для проверки подлинности, а также записи и чтения BLOB-объектов в Хранилище BLOB-объектов Azure SQL Server может использовать либо имя учетной записи хранения Azure и значение ее ключа доступа, либо маркер подписанного URL-адреса, созданный в определенных контейнерах и предоставляющий права на чтение и запись. Дополнительные сведения об учетных записях хранения Azure см. в разделе Об учетных записях хранения Azure , а дополнительные сведения о подписанных URL-адресах (SAS) см. в статье Подписанные URL-адреса. Часть 1. Общие сведения о модели SAS. Учетные данные SQL Server не только хранят эти сведения для проверки подлинности, но и используют их во время операций резервного копирования или восстановления.
Служба хранилища Azure и хранилище, совместимое с S3
В SQL Server 2012 с пакетом обновления 1 (CU2) и SQL Server 2014 появилась возможность резервного копирования на URL-адрес, указывающий на Хранилище BLOB-объектов Azure, используя знакомый синтаксис T-SQL для безопасной записи резервных копий в хранилище Azure. В SQL Server 2016 (13.x) впервые появились резервные копии моментальных снимков файлов для файлов базы данных в Azure и защита с помощью ключей подписанного URL-адреса (SAS) — безопасный и простой способ проверки подлинности сертификатов в политике безопасности службы хранилища Azure. 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, см. в разделе Резервное копирование и восстановление SQL Server по URL-адресу хранилища объектов, совместимого с S3.
Резервное копирование в блочный и страничный BLOB-объекты службы хранилища Azure
Существует два типа BLOB-объектов, которые можно хранить в Хранилище BLOB-объектов Microsoft Azure: блочные и страничные BLOB-объекты. Для SQL Server 2016 и более поздних версий рекомендуется использовать блочный BLOB-объект.
Если в учетных данных указан ключ к хранилищу данных, будет использоваться страничный BLOB-объект, а если подписанный URL-адрес — блочный BLOB-объект.
Резервное копирование в блочный BLOB-объект Хранилища BLOB-объектов Azure доступно только в SQL Server 2016 или более поздней версии. Выполняйте резервное копирование в блочный BLOB-объект вместо страничного в случае, если у вас запущен 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. Дополнительные сведения о больших двоичных объектах см. в разделе Основные сведения о блочных и страничных больших двоичных объектах.
Моментальный снимок 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.
Безопасность Хранилища BLOB-объектов Azure
Далее описаны вопросы безопасности и требования к резервному копированию и восстановлению с помощью Хранилища BLOB-объектов Azure.
При создании контейнера для Хранилища BLOB-объектов Azure рекомендуется установить для него частные права доступа. Установка закрытых прав доступа означает, что доступ получают только те пользователи и учетные записи, которые могут предоставить необходимую информацию для проверки подлинности в учетной записи Azure.
Внимание
SQL Server требует, чтобы имя учетной записи Azure и проверка подлинности ключа доступа или подписанный URL-адрес и маркер доступа хранились в учетных данных SQL Server. Эти сведения используются для проверки подлинности учетной записи Azure при резервном копировании или восстановлении.
Предупреждение
Служба хранилища Azure поддерживает отключение авторизации с общим ключом для учетной записи хранения. Если авторизация с общим ключом отключена, операция SQL Server "Резервное копирование по 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.
Функция присоединения к существующим резервным большим двоичным объектам не поддерживается. Резервное копирование в существующий большой двоичный объект можно осуществлять только путем перезаписи с помощью параметра WITH FORMAT . Однако при использовании резервных копий моментальных снимков файлов (с помощью аргумента WITH FILE_SNAPSHOT ) аргумент WITH FORMAT не разрешен, чтобы избежать появления потерянных моментальных снимков файлов, которые были созданы во время первоначального резервного копирования снимков файлов.
Резервное копирование в несколько больших двоичных объектов в одной операции резервного копирования поддерживается только при использовании блочных больших двоичных объектов и с помощью токена SAS, а не ключа учетной записи хранения для учетных данных SQL.
Параметр BLOCKSIZE для страничных BLOB-объектов не поддерживается.
Параметр MAXTRANSFERSIZE для страничных BLOB-объектов не поддерживается.
Указание параметров резервного набора данных RETAINDAYS и EXPIREDATE не поддерживается.
SQL Server имеет максимальное ограничение в 259 символов для имени устройства резервного копирования. Функция BACKUP TO URL использует 36 символов для необходимых элементов, которые нужны для указания URL (https://.blob.core.windows.net//.bak), оставляя 223 символа для имен учетной записи, контейнера и большого двоичного объекта.
Версии SQL Server до 2022 года имеют ограничение в 256 символов для маркеров подписанного URL-адреса (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 | Поддерживается | Исключения | Комментарии |
|---|---|---|---|
| BACKUP | Y | BLOCKSIZE и MAXTRANSFERSIZE поддерживаются для блочных BLOB-объектов. Они не поддерживаются для страничных BLOB-объектов. | Для резервного копирования в блочный BLOB-объект требуется сохранить подписанный URL-адрес в учетных данных SQL Server. Для резервного копирования на страницу BLOB-объекта требуется ключ учетной записи хранения, сохраненный в учетных данных SQL Server, и требуется указать аргумент WITH CREDENTIAL. |
| RESTORE | Y | Требуется определить учетные данные SQL Server и указать аргумент WITH CREDENTIAL, если учетные данные SQL Server определены с помощью ключа учетной записи хранения в качестве секрета. | |
| RESTORE FILELISTONLY | Y | Требуется определить учетные данные SQL Server и указать аргумент WITH CREDENTIAL, если учетные данные SQL Server определены с помощью ключа учетной записи хранения в качестве секрета. | |
| инструкция RESTORE HEADERONLY | Y | Требуется определить учетные данные SQL Server и указать аргумент WITH CREDENTIAL, если учетные данные SQL Server определены с помощью ключа учетной записи хранения в качестве секрета. | |
| RESTORE LABELONLY | Y | Требуется определить учетные данные SQL Server и указать аргумент WITH CREDENTIAL, если учетные данные SQL Server определены с помощью ключа учетной записи хранения в качестве секрета. | |
| RESTORE VERIFYONLY | Y | Требуется определить учетные данные SQL Server и указать аргумент WITH CREDENTIAL, если учетные данные SQL Server определены с помощью ключа учетной записи хранения в качестве секрета. | |
| RESTORE REWINDONLY | - |
Общую информацию и синтаксис инструкций резервного копирования см. в разделе BACKUP (Transact-SQL).
Общую информацию и синтаксис инструкций восстановления см. в разделе RESTORE (Transact-SQL).
Поддержка аргументов резервного копирования в Хранилище BLOB-объектов Azure
| Аргумент | Поддерживается | Исключение | Комментарии |
|---|---|---|---|
| DATABASE | Y | ||
| ЖУРНАЛ | Y | ||
| TO (URL) | Y | В отличие от DISK и TAPE URL-адрес не поддерживает функцию указания или создания логического имени. | Этот аргумент используется, чтобы указать URL-адрес для файла резервной копии. |
| MIRROR TO | Y | ||
| WITH OPTIONS: | |||
| CREDENTIAL | Y | WITH CREDENTIAL поддерживается только при использовании параметра BACKUP TO URL для резервного копирования в Хранилище BLOB-объектов Azure и только если учетные данные SQL Server определяются с использованием ключа учетной записи хранения в качестве секрета. | |
| FILE_SNAPSHOT | Y | ||
| ШИФРОВАНИЕ | Y | При указании аргумента WITH ENCRYPTION резервное копирование файлов SQL Server гарантирует, что вся база данных была зашифрована TDE перед выполнением резервной копии и, если да, шифрует файл резервного копирования моментальных снимков файлов с помощью алгоритма, указанного для TDE в базе данных. Если все данные во всей базе данных не зашифрованы, произойдет сбой резервного копирования (например, когда процесс шифрования еще не завершен). | |
| DIFFERENTIAL (разностная) | Y | ||
| COPY_ONLY | Y | ||
| СЖАТИЕ|NO_COMPRESSION | Y | Не поддерживается для резервного копирования моментальных снимков файлов. | |
| ОПИСАНИЕ | Y | ||
| ИМЯ | Y | ||
| ИСТЕК СРОК ДЕЙСТВИЯ | RETAINDAYS | - | ||
| NOINIT | INIT | - | Добавление к большим двоичным объектам невозможно. Для перезаписи резервной копии используйте аргумент WITH FORMAT. Однако при использовании резервных копий моментальных снимков файлов (с помощью аргумента WITH FILE_SNAPSHOT ) аргумент WITH FORMAT не разрешен, чтобы избежать появления потерянных моментальных снимков файлов, которые были созданы во время первоначального резервного копирования. | |
| NOSKIP | СКИП | - | ||
| NOFORMAT | ФОРМАТ | Y | Создание резервных копий в существующем большом двоичном объекте завершается ошибкой, если не указан аргумент WITH FORMAT . Если аргумент WITH FORMAT указан, существующий большой двоичный объект будет перезаписан. Однако при использовании резервных копий моментальных снимков файлов (с помощью аргумента WITH FILE_SNAPSHOT ) аргумент FORMAT не разрешен, чтобы избежать появления потерянных моментальных снимков файлов, которые были созданы во время первоначального резервного копирования снимков файлов. Однако при использовании резервных копий моментальных снимков файлов (с помощью аргумента WITH FILE_SNAPSHOT ) аргумент WITH FORMAT не разрешен, чтобы избежать появления потерянных моментальных снимков файлов, которые были созданы во время первоначального резервного копирования. | |
| MEDIADESCRIPTION | Y | ||
| MEDIANAME | Y | ||
| BLOCKSIZE | Y | Не поддерживается для страничных BLOB-объектов. Поддерживается для блочных BLOB-объектов. | Для оптимизации использования 50 000 блоков, допустимых в блочном BLOB-объекте, рекомендуемый размер блока BLOCKSIZE составляет 65 536 байт. |
| BUFFERCOUNT | Y | ||
| MAXTRANSFERSIZE | Y | Не поддерживается для страничных BLOB-объектов. Поддерживается для блочных BLOB-объектов. | Значение по умолчанию составляет 1 048 576 байт. Значение может изменяться в диапазоне до 4 МБ с шагом в 65 536 байт. Для оптимизации использования 50 000 блоков, допустимых в блочном BLOB-объекте, рекомендуемый размер функции MAXTRANSFERSIZE составляет 4 194 304 байт. |
| NO_CHECKSUM | КОНТРОЛЬНАЯ СУММА | Y | ||
| STOP_ON_ERROR | CONTINUE_AFTER_ERROR | Y | ||
| СТАТИСТИКА | Y | ||
| REWIND | NOREWIND | - | ||
| ВЫГРУЗКА | NOUNLOAD | - | ||
| NORECOVERY | РЕЗЕРВНЫЙ | Y | ||
| NO_TRUNCATE | Y |
Дополнительные сведения об аргументах резервного копирования см. в разделе BACKUP (Transact-SQL).
Поддержка аргументов восстановления в Хранилище BLOB-объектов Azure
| Аргумент | Поддерживается | Исключения | Комментарии |
|---|---|---|---|
| DATABASE | Y | ||
| ЖУРНАЛ | Y | ||
| FROM (URL) | Y | Аргумент FROM URL используется, чтобы указать URL-адрес для файла резервной копии. | |
| WITH Options: | |||
| CREDENTIAL | Y | WITH CREDENTIAL поддерживается только при использовании параметра RESTORE FROM URL для восстановления из Хранилища BLOB-объектов Azure. | |
| PARTIAL | Y | ||
| ВОССТАНОВЛЕНИЕ | NORECOVERY | РЕЗЕРВНЫЙ | Y | ||
| LOADHISTORY | Y | ||
| MOVE | Y | ||
| ЗАМЕНИТЬ | Y | ||
| ПЕРЕЗАПУСК | Y | ||
| RESTRICTED_USER | Y | ||
| ФАЙЛ | - | ||
| ПАРОЛЬ | Y | ||
| MEDIANAME | Y | ||
| MEDIAPASSWORD | Y | ||
| BLOCKSIZE | Y | ||
| BUFFERCOUNT | - | ||
| MAXTRANSFERSIZE | - | ||
| КОНТРОЛЬНАЯ СУММА | NO_CHECKSUM | Y | ||
| STOP_ON_ERROR | CONTINUE_AFTER_ERROR | Y | ||
| FILESTREAM | Y | Не поддерживается для резервного копирования моментальных снимков. | |
| СТАТИСТИКА | Y | ||
| REWIND | NOREWIND | - | ||
| ВЫГРУЗКА | NOUNLOAD | - | ||
| KEEP_REPLICATION | Y | ||
| KEEP_CDC | Y | ||
| ENABLE_BROKER | ERROR_BROKER_CONVERSATIONS | NEW_BROKER | Y | ||
| STOPAT | STOPATMARK | STOPBEFOREMARK | Y |
Дополнительные сведения об аргументах восстановления см. в разделе Аргументы RESTORE (Transact-SQL).
Резервное копирование с помощью SSMS
С помощью этой задачи можно выполнять резервное копирование на URL-адрес с использованием учетных данных SQL Server.
Примечание.
Чтобы создать резервную копию моментальных снимков файлов SQL Server или перезаписать существующий набор носителей, необходимо использовать Transact-SQL, Powershell или C# вместо задачи резервного копирования в SQL Server Management Studio.
Ниже приведены инструкции по внесению изменений в задачу "Резервное копирование базы данных" в SQL Server Management Studio для создания резервной копии в хранилище Azure.
В обозревателе объектовподключитесь к экземпляру компонента SQL Server Database Engine и разверните его.
Разверните узел Базы данных, щелкните правой кнопкой мыши нужную базу данных, наведите указатель на пункт Задачи и выберите Создать резервную копию....
На странице Общие в разделе Назначение в раскрывающемся списке Создать резервную копию на: доступен вариант URL-адрес . Параметр URL-адрес используется для создания резервной копии в хранилище Windows Azure. Нажмите кнопку Добавить, чтобы открыть диалоговое окно Выбор назначения резервной копии.
Контейнер хранилища Azure. Имя контейнера хранилища Windows Azure для хранения файлов резервной копии. Выберите существующий контейнер в раскрывающемся списке или введите контейнер вручную.
Политика подписанных URL-адресов. Введите подписанный URL-адрес для контейнера, указанного вручную. Это поле недоступно, если был выбран существующий контейнер.
Файл резервной копии. Имя файла резервной копии.
Новый контейнер. Используется для регистрации существующего контейнера, который не имеет подписанного URL-адреса. См. раздел Соединение с подпиской Microsoft Azure.
Примечание.
Добавить поддерживает несколько файлов резервных копий и контейнеров хранилища для одного набора носителей.
При выборе URL-адреса в качестве назначения некоторые параметры на странице Параметры носителя отключаются. В следующих разделах приводятся дополнительные сведения о диалоговом окне "Резервное копирование базы данных".
Архивация базы данных (страница "Параметры резервного копирования")
Создание учетных данных — проверка подлинности в хранилище Azure
Резервное копирование с помощью плана обслуживания
Как и в описанной выше задаче резервного копирования, мастер плана обслуживания в SQL Server Management Studio включает URL-адрес в качестве одного из вариантов назначения и другие вспомогательные объекты, необходимые для резервного копирования в хранилище Azure, например учетные данные SQL. Дополнительные сведения см. в разделе Определение задач резервного копирования статьи Using Maintenance Plan Wizard.
Примечание.
Чтобы создать полосатый набор резервных копий, резервную копию моментальных снимков файлов SQL Server или учетные данные SQL с помощью маркера общего доступа, необходимо использовать Transact-SQL, PowerShell или C# вместо задачи резервного копирования в мастере планов обслуживания.
Восстановление с помощью SSMS
При восстановлении базы данных URL-адрес включается в качестве устройства, с которого следует выполнить восстановление. Следующие шаги описывают использование задачи восстановления для восстановления из Хранилища BLOB-объектов Azure.
Щелкните правой кнопкой мыши узел Базы данных и выберите команду Восстановить базу данных...
На странице Общие выберите пункт Устройство в разделе Источник .
Нажмите кнопку обзора (...), чтобы открыть диалоговое окно Выбор устройств резервного копирования.
Выберите URL-адрес в раскрывающемся списке Тип носителя резервной копии: . Нажмите кнопку Добавить, чтобы открыть диалоговое окно Выбор расположения файла резервной копии.
Контейнер хранилища Azure: полное имя контейнера хранилища Microsoft Azure, содержащего файлы резервного копирования. Выберите существующий контейнер в раскрывающемся списке или введите полное имя контейнера вручную.
Подписанный URL-адрес. Используется для ввода подписанного URL-адреса для назначенного контейнера.
Добавить. Используется для регистрации существующего контейнера, который не имеет подписанного URL-адреса. См. раздел Соединение с подпиской Microsoft Azure.
ОК. 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. Выполните одно из следующих действий.
Использование подписанного 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>';Использование удостоверения учетной записи хранения и ключа доступа
IF NOT EXISTS (SELECT * FROM sys.credentials WHERE name = '<mycredentialname>') CREATE CREDENTIAL [<mycredentialname>] WITH IDENTITY = '<mystorageaccountname>' ,SECRET = '<mystorageaccountaccesskey>';
Выполнение полного резервного копирования базы данных
В следующих примерах выполняется полная резервная копия AdventureWorks2022 базы данных для Хранилище BLOB-объектов Azure. Используйте один из следующих примеров:
На URL-адрес с использованием подписанного URL-адреса
BACKUP DATABASE AdventureWorks2022 TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak'; GOНа 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