Резервное копирование SQL Server на URL-адрес — рекомендации и устранение неполадок.

Статья
03/06/2017

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

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

Управление резервными копиями

В следующем списке перечислены общие рекомендации по управлению резервным копированием.

Рекомендуется присваивать каждому файлу уникальное имя, чтобы предотвратить случайное перезаписывание больших двоичных объектов.
При создании контейнера рекомендуется установить уровень доступа private, чтобы большие двоичные объекты в контейнере могли читать или записывать только те пользователи или учетные записи, которые предоставили необходимую информацию для проверки подлинности.
Для баз данных SQL Server на экземпляре SQL Server, работающем на виртуальной машине Azure, используйте учетную запись хранения в том же регионе, что и виртуальная машина, чтобы избежать затрат на передачу данных между регионами. Использование одного региона также обеспечивает оптимальную производительность операций резервного копирования и восстановления.
Сбой во время резервного копирования может привести к созданию неработоспособного файла резервной копии. Рекомендуется периодически проводить поиск неудачных резервных копий и удалять файлы больших двоичных объектов. Дополнительные сведения см. в разделе Deleting Backup Blob Files with Active Leases.
Использование параметра WITH COMPRESSION во время резервного копирования может уменьшить стоимость хранения и транзакционные издержки хранения. Также может сократиться время, необходимое для выполнения резервного копирования.

Обработка больших файлов

Операция резервного копирования SQL Server использует несколько потоков для оптимизации передачи данных в службы хранилища BLOB-объектов Azure. Однако производительность зависит от различных факторов, в том числе от пропускной способности ISV и размера базы данных. Если планируется создавать резервные копии больших баз данных или файловых групп в локальной базе данных SQL Server, вначале рекомендуется проверить пропускную способность. Соглашение об уровне обслуживания хранилища Azure имеет максимальное время обработки больших двоичных объектов, которые можно учитывать.
При создании резервных копий больших файлов очень важно использовать параметр WITH COMPRESSION в соответствии с рекомендациями, приведенными в разделе Управление резервным копированием.

Устранение неполадок при резервном копирование или восстановлении по URL-адресу

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

Чтобы избежать ошибок из-за неподдерживаемых параметров или ограничений, просмотрите список ограничений и поддержку команд BACKUP и RESTORE в статье службы SQL Server Backup and Restore Хранилище BLOB-объектов Azure.

Ошибки проверки подлинности:

WITH CREDENTIAL — это новый параметр, который требуется для резервного копирования или восстановления из службы хранилища BLOB-объектов Azure. Ниже приводятся возможные ошибки, связанные с учетными данными.

Учетные данные, заданные в команде BACKUP или RESTORE, не существуют. Чтобы избежать этой проблемы, можно включить инструкцию T-SQL для создания учетных данных, если она отсутствует в инструкции резервного копирования. Ниже приводится пример, который можно использовать.
```
IF NOT EXISTS  
(SELECT * FROM sys.credentials   
WHERE credential_identity = 'mycredential')  
CREATE CREDENTIAL <credential name> WITH IDENTITY = 'mystorageaccount'  
,SECRET = '<storage access key> ;  
```
Учетные данные существуют, но учетная запись, которая используется для запуска команды резервного копирования, не имеет разрешения доступа к учетным данным. Используйте учетную запись для входа в роль db_backupoperator с разрешением Изменение любых учетных данных.
Проверьте имя учетной записи хранилища и значение ключа. Информация, которая хранится в учетных данных, должна соответствовать значениям свойств учетной записи хранения Azure, используемым в операциях резервного копирования и восстановления.

Ошибки и сбои резервного копирования:

Параллельное выполнение резервного копирования в один большой двоичный объект вызывает сбой одной из резервных копий с ошибкой Ошибка инициализации .
Используйте следующие журналы об ошибке, чтобы помочь при устранении неполадок в резервных ошибках:
- Установите флаг трассировки 3051, чтобы включить ведение записей в конкретном журнале ошибок в следующем формате:
  
  BackupToUrl-instname-dbname-action-PID<<>>><.log Где <одно из следующих действий:>
  - DB
  - FILELISTONLY
  - LABELONLY
  - HEADERONLY
  - VERIFYONLY
- Вы также можете найти сведения, просмотрив журнал событий Windows в журналах приложений с именем SQLBackupToUrl.
При восстановлении из сжатой резервной копии может появиться следующее сообщение об ошибке:
- Возникло исключение SqlException 3284. Серьезность: 16, состояние: 5
  Файл сообщения на устройстве "https://mystorage.blob.core.windows.net/mycontainer/TestDbBackupSetNumber2_0.bak" не выровнен. Перезапустите инструкцию Restore с тем же размером блока, который использовался при создании резервного набора данных. Возможно, следует указать 65536.
  
  Чтобы устранить эту ошибку, перезапустите инструкцию BACKUP с помощью заметки BLOCKSIZE = 65536.
Ошибка во время архивации из-за больших двоичных объектов с активной арендой: сбой операции архивации может привести к появлению больших двоичных объектов с активными арендами.

Если эта инструкция резервного копирования повторяется, то операция резервного копирования может завершиться со следующей ошибкой:

Резервное копирование на URL-адрес получило исключение от удаленной конечной точки. Сообщение об исключении: удаленный сервер вернул ошибку: (412) В настоящее время имеется аренда большого двоичного объекта и в запросе не указан идентификатор аренды..

Если инструкция восстановления выполнялись в резервном файле большого двоичного объекта с активной арендой, операция резервного копирования может завершиться со следующей ошибкой:

Сообщение об исключении: удаленный сервер вернул ошибку: (409) конфликт…

Если возникает такая ошибка, файлы больших двоичных объектов следует удалить. Дополнительные сведения об этом сценарии и устранении этой проблемы см. в разделе Deleting Backup Blob Files with Active Leases.

Ошибки прокси-сервера

При использовании прокси-серверов для доступа к Интернету возможны следующие проблемы.

Регулирование соединений прокси-серверами.

Прокси-серверы могут иметь параметры, ограничивающие количество соединений в минуту. Процесс резервного копирования на URL-адрес является многопоточным, в связи с чем заданное ограничение может быть превышено. В этом случае прокси-сервер разрывает соединение. Чтобы устранить эту проблему, измените параметры прокси-сервера таким образом, чтобы SQL Server его не использовал. Далее приведено несколько примеров типов или сообщений об ошибках, которые можно встретить в журнале ошибок.

Напишите на "http://storageaccount.blob.core.windows.net/container/BackupAzurefile.bak" Не удалось выполнить резервное копирование по URL-адресу, полученное из удаленной конечной точки. Сообщение об исключении: не удалось прочитать данные из транспортного соединения. Соединение было закрыто.
В файле произошла неустранимая ошибка ввода-вывода;http://storageaccount.blob.core.windows.net/container/BackupAzurefile.bak:" Ошибка не удалось собрать из удаленной конечной точки.

Сообщение 3013, уровень 16, состояние 1, строка 2

РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ завершено с ошибкой.
BackupIoRequest::ReportIoError: сбой записи на устройстве резервного копирования 'http://storageaccount.blob.core.windows.net/container/BackupAzurefile.bak'. Ошибка операционной системы. Процесс резервного копирования на URL-адрес получил исключение от удаленной конечной точки. Сообщение об исключении: не удалось прочитать данные из транспортного соединения. Соединение было закрыто.

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

Код состояния HTTP 502, ошибка прокси-сервера сообщения состояния HTTP (число HTTP-запросов в минуту превысило настроенное ограничение. Обратитесь к администратору сервера ISA. )

Параметры прокси-сервера по умолчанию не используются.

Иногда параметры по умолчанию не выбираются, что приводит к ошибкам проверки подлинности прокси-сервера, таким как показанная ниже: ошибка неустранимого ввода-вывода произошла в файле "http://storageaccount.blob.core.windows.net/container/BackupAzurefile.bak:" Резервное копирование по URL-адресу, полученное из удаленной конечной точки. Сообщение об исключении: удаленный сервер вернул ошибку: (407) Требуется проверка подлинности прокси-сервера.

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

Создайте файл конфигурации BackuptoURL.exe.config со следующим XML-кодом:

<?xml version ="1.0"?>  
<configuration>   
                <system.net>   
                                <defaultProxy enabled="true" useDefaultCredentials="true">   
                                                <proxy usesystemdefault="true" />   
                                </defaultProxy>   
                </system.net>  
</configuration>

Поместите файл конфигурации в папку Binn экземпляра SQL Server. Например, если сервер SQL Server установлен на диске C компьютера, поместите файл конфигурации здесь: C:\Program Files\Microsoft SQL Server\MSSQL12.<InstanceName>\MSSQL\Binn.

Устранение неполадок с управляемым резервным копированием SQL Server в Azure

Так как служба управляемого резервного копирования SQL Server использует операцию копирования на URL-адрес, советы по устранению проблемы, описанные в предыдущих подразделах, относятся к базам данных и экземплярам, использующим данную службу. Сведения об устранении неполадок управляемого резервного копирования SQL Server в Azure подробно описаны в статье "Устранение неполадок управляемого резервного копирования SQL Server в Azure".

См. также

Восстановление из резервных копий, хранящихся в Azure

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