Рекомендованные методы резервного копирования и восстановления (служба хранилищ больших двоичных объектов Windows Azure)

Статья
02/18/2014

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

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

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

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

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

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

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

Оптимизация восстановления

Чтобы снизить время восстановления, добавьте учетной записи пользователя SQL Server право Выполнение задач по обслуживанию томов. Дополнительные сведения см. в разделе Инициализация файлов базы данных

Вопросы производительности

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

Значения продолжительности резервного копирования и восстановления пропорциональны пропускной способности сети.
Минимальная пропускная способность сети для резервного копирования составляет 1 МБ в секунду. Если пропускная способность меньше 1 МБ в секунду, резервное копирование может окончиться неудачей из-за ошибок, связанных с истечением времени ожидания.
Время восстановления также пропорционально задержке в сети, особенно если предпринимается попытка восстановить файл из региона Windows Azure с иным географическим расположением по сравнению с экземпляром SQL Server, на котором должно быть выполнено восстановление. В таких случаях возрастает значение тестирования, которое позволяет убедиться в том, что соблюдение требований RTO возможно.

Устранение неполадок при резервном копировании или восстановлении из службы хранилища больших двоичных объектов Windows Azure

Ниже перечислены некоторые простые способы устранения ошибок, возникающих при резервном копировании или восстановлении с применением службы хранилища больших двоичных объектов Windows Azure.

Чтобы избежать ошибок из-за неподдерживаемых параметров или ограничений, просмотрите список ограничений и информацию о поддержке для команд BACKUP и RESTORE в статье Резервное копирование и восстановление SQL Server с помощью службы хранилищ больших двоичных объектов Windows Azure.

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

WITH CREDENTIAL — это новый параметр, который необходимо использовать при создании резервных копий или восстановлении с помощью службы хранилища больших двоичных объектов Windows 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 с разрешениями Alter any credential.
Проверьте имя учетной записи хранилища и значение ключа. Информация, которая хранится в учетных данных, должна соответствовать значениям свойств учетной записи хранилища Windows Azure, которые используются в операциях резервного копирования и восстановления.

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

Параллельное выполнение резервного копирования в один большой двоичный объект вызывает сбой одной из резервных копий с ошибкой Ошибка инициализации.
Используйте следующие журналы об ошибке, чтобы помочь при устранении неполадок в резервных ошибках:
- Установите флаг трассировки 3051, чтобы включить ведение записей в конкретном журнале ошибок в следующем формате:
  
  BackupToUrl-<instname>-<dbname>-action-<PID>.log, где <action> может принимать одно из следующих значений:
  - DB
  - FILELISTONLY
  - LABELONLY
  - HEADERONLY
  - VERIFYONLY
- Дополнительную информацию можно найти в журнале событий Windows или в журналах приложений с именем «SQLBackupToUrl».
Ошибка во время резервного копирования из-за больших двоичных объектов с активной арендой: Сбой операции резервного копирования может привести к созданию больших двоичных объектов с активными арендами.

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

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

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

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

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

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

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

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

Прокси-серверы могут иметь параметры, ограничивающие количество соединений в минуту. Процесс резервного копирования на 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. )

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

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