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

Применимо к:SQL ServerУправляемый экземпляр SQL Azure

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

Overview

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

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

Создание учетной записи служба хранилища Azure в подписке Azure является первым шагом в этом процессе. Эта учетная запись хранения является административной учетной записью, имеющей полные административные разрешения на все контейнеры и объекты, созданные с помощью этой учетной записи хранения. SQL Server может использовать имя учетной записи хранения Azure и значение ее ключа доступа для аутентификации, чтения и записи данных в Хранилище BLOB-объектов Azure, или использовать маркер SAS, сгенерированный для определенных контейнеров, предоставляющий права на чтение и запись. Дополнительные сведения об учётных записях хранилища Azure см. в статье About Azure Storage Accounts, а дополнительные сведения о подписях для общего доступа (Shared Access Signatures, SAS) см. в статье Shared Access Signatures, часть 1: Общие сведения о модели SAS. Учетные данные SQL Server хранят эти сведения проверки подлинности и используются во время операций резервного копирования или восстановления.

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

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

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

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

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

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

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

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

• По сравнению с ключом хранения, Shared Access Signature (подписанная строка доступа) является более безопасным способом авторизации доступа к BLOB.
• Вы можете создать резервную копию до нескольких блочных BLOB-объектов, чтобы повысить производительность резервного копирования и восстановления, а также обеспечить более крупную резервную копию базы данных.
• Блочный большой двоичный объект дешевле , чем страничный BLOB-объект.
• Клиентам, которым необходимо выполнить копирование данных на блобы страниц через прокси-сервер, следует использовать backuptourl.exe.

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

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

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

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

Если экземпляр SQL Server размещен в Linux, в том числе:

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

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

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

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

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

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

Azure Снимок: снимок объекта BLOB Azure, сделанный на определенный момент времени. Дополнительную информацию см. в разделе Создание моментального снимка Blob-объекта. SQL Server теперь поддерживает создание моментальных снимков Azure резервных копий файлов базы данных, хранящихся в Хранилище BLOB-объектов Azure. Дополнительные сведения см. в разделе File-Snapshot Резервные копии для файлов базы данных в Azure.

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

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

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

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

Пример создания Подписи общего доступа см. в разделе Create a Shared Access Signature примеры ниже в этой статье. Для создания учетных данных SQL Server см. раздел примеры Создание учетных данных ниже в этой статье.

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

Дополнительные сведения о других примерах использования учетных данных см. в разделе Create a агент SQL Server Proxy.

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

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

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

Azure хранилище предоставляет два типа неизменяемости, уровня контейнера и уровня версии. В настоящее время поддерживается только неизменяемое хранилище уровня контейнера.

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

1. Настройте неизменяемость для контейнера хранилища Azure.

2. Выполните BACKUP для резервного копирования базы данных в контейнер хранилища Azure. Если вы используете WITH FORMAT параметр в неизменяемом хранилище, а резервная копия уже существует с тем же именем, вы получите ошибку и сбой резервной копии.

   BACKUP DATABASE [<Database>] TO URL = '<url>';
   

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

Ниже приведены рекомендации по обеспечению безопасности и требования при резервном копировании или восстановлении из Хранилище BLOB-объектов Azure.

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

  Important

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

  Warning

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

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

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

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

  Important

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

• Резервные копии журналов транзакций игнорируют указанные пользователем MAXTRANSFERSIZE при резервном копировании в несколько файлов резервных копий. Вместо этого используется 64 КБ, если указано несколько файлов независимо от MAXTRANSFERSIZE значения в команде резервного копирования. Таким образом, максимальный размер резервной копии журнала транзакций по URL-адресу составляет примерно 195,3 ГБ (50 000 блоков * 4 МБ MAXTRANSFERSIZE * 1 файл ИЛИ 50 000 блоков * 64 КБ * 64 файла). Сжатие может позволить создать резервную копию большого журнала транзакций, но коэффициенты сжатия будут отличаться.

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

• При резервном копировании в учетную запись хранилища Azure SQL Server поддерживает только аутентификацию с помощью токенов общей подписи (SAS) или ключей учетной записи хранилища. Все другие методы проверки подлинности, включая проверку подлинности с помощью Microsoft Entra ID (формерно 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 символов для имени устройства резервного копирования. Элемент BACKUP TO URL использует 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 не поддерживается раньше SQL Server 2025 г. Задайте для политики неизменяемого хранилища значение false.

• Сведения о поддержке в SQL Server 2025 и более поздних версиях см. в разделе Azure поддержка неизменяемого хранилища.

  • Azure хранилище предоставляет два типа неизменяемости, уровня контейнера и уровня версии. В настоящее время поддерживается только неизменяемое хранилище уровня контейнера.

• Резервное копирование по URL-адресу не поддерживается в хранилище класса Premium.

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

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

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

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

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

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

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

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

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

Вы можете создать резервную копию базы данных по URL-адресу с помощью задачи резервного копирования в SQL Server Management Studio с помощью учетных данных SQL Server.

Ниже описаны изменения, внесенные в задачу резервного копирования базы данных в SQL Server Management Studio, чтобы обеспечить резервное копирование до хранилища Azure:

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

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

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

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

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

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

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

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

• Архивация базы данных (страница "Общие")
• Резервное копирование базы данных (страница "Параметры мультимедиа")
• Архивация базы данных (страница "Параметры резервного копирования")
• Create Credential — аутентификация в служба хранилища Azure

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

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

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

Задача "Восстановить базу данных" включает URL-адрес в качестве средства для восстановления. Ниже описано использование задачи восстановления для восстановления из Хранилище BLOB-объектов Azure.

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

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

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

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

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

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

   3. Добавить: Используется для регистрации существующего контейнера, для которого у вас нет общей подписи доступа. См. раздел Connect to a Microsoft Azure Subscription (Backup TO URL).

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

      • Восстановление базы данных (страница "Общие")
      • Восстановление базы данных (страница "Файлы")
      • Восстановление базы данных (страница "Параметры")

Примеры кода

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

• Создание общей сигнатуры доступа
• Создание учетных данных
• Выполнение полного резервного копирования базы данных
• Восстановление до определённой точки во времени с помощью stopat

Создание Подписанного ключа доступа

В следующем примере создаются подписи общего доступа, которые можно использовать для создания учетных данных SQL Server в новом контейнере. Этот скрипт создает маркер совместного доступа, связанный с хранимой политикой доступа. Дополнительные сведения см. в статье Общие ключи доступа, часть 1: понимание модели SAS. Скрипт также записывает команду T-SQL, необходимую для создания учетных данных в SQL Server.

Подписанный 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 и выполните команду для создания учетных данных с Shared Access Signature.

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

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

1. Использование подписанного 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>';
   

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

В следующих примерах выполняется полная резервная копия базы данных AdventureWorks2025 для Хранилище 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

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

С 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

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

• Рекомендации по резервному копированию SQL Server в Microsoft Хранилище BLOB-объектов Azure по URL-адресу: лучшие практики и устранение неполадок
• Резервное копирование и восстановление: системные базы данных (SQL Server)
• Туториал: используйте Хранилище BLOB-объектов Azure с SQL Server