Резервное копирование 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 Резервное копирование и восстановление с помощью службы Хранилище 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

Процесс BACKUP DATABASE завершается аварийно.
BackupIoRequest::ReportIoError: сбой записи на устройстве резервного копирования "http://storageaccount.blob.core.windows.net/container/BackupAzurefile.bak". Ошибка операционной системы. Процесс резервного копирования на URL-адрес получил исключение от удаленной конечной точки. Сообщение об исключении: не удалось прочитать данные из транспортного соединения. Соединение было закрыто.

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

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

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

Иногда параметры по умолчанию не выбираются, что приводит к ошибкам проверки подлинности прокси-сервера, например показанным ниже:Ошибка неустранимого ввода-вывода произошла в файле "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.<Имя_>экземпляра\MSSQL\Binn.

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

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

См. также:

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

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