Почему MS SQL Server добавляет двойные слэши в путь бэкапа и как исправить ошибки резервного копирования

← На главную

При настройке регулярного резервного копирования баз данных MS SQL Server на удаленный сетевой ресурс администраторы нередко сталкиваются с падением регламентных заданий. В журнале выполнения запроса при этом путь к целевому каталогу отображается с удвоенными обратными слэшами вида \\\\192.168.10.2\\backup\\..., а сама операция прерывается системной ошибкой 64 или ошибкой парсера 155. Разберем детально, почему так происходит, изменяет ли SQL Server исходный T-SQL скрипт на самом деле и как правильно организовать отказоустойчивое резервное копирование.

Рассмотрим типовой сценарий резервного копирования, вызывающий подобные вопросы:


DECLARE @Nw3 NVARCHAR(512);
SET @Nw3 = '\\192.168.10.2\bukh\bukh_' + Convert(varchar(8), GETDATE(), 112) + '.bak';

BACKUP DATABASE [bukh] 
TO DISK = @Nw3 
WITH NOFORMAT, INIT, NAME = N'db_backup', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;

1. Почему в логах появляются лишние обратные слэши

Проанализируем природу появления двойных обратных слэшей в тексте ошибки. В сообщениях об ошибках SQL Server и агента заданий строка пути действительно выводится в формате \\\\192.168.10.2\\bukh\\.... Из-за этого может сложиться ошибочное впечатление, что СУБД самостоятельно подменяет путь к файлу.

На самом деле SQL Server не добавляет лишние символы в сформированную строковую переменную. В этом легко убедиться, выполнив вывод значения переменной в консоль через команду SELECT @Nw3; — на экран вернется корректный путь с одиночными разделителями.

Удвоение символа обратного слэша в сообщениях об ошибках — это стандартный системный механизм экранирования (escaping) служебных символов в подсистемах логирования SQL Server и служб интеграции (SSIS). Так как обратный слэш является управляющим символом во многих языках программирования и внутренних парсерах, механизм вывода журналов дублирует его для однозначной строковой интерпретации. В ядро СУБД для выполнения операции всегда передается исходный путь без лишних символов.

2. Причины и устранение ошибки операционной системы 64

Если в журнале зафиксировано сообщение: Невозможно открыть устройство резервного копирования. Ошибка операционной системы 64 (Указанное сетевое имя более недоступно.), это означает, что сетевое соединение между сервером базы данных и целевым SMB-хранилищем было принудительно разорвано в процессе записи потока данных.

Выясним основные причины возникновения этой проблемы:

Сброс TCP-соединения сетевым адаптером: при передаче больших объемов данных механизмы аппаратной разгрузки сетевой карты могут вызывать сбои и микрообрывы сессии.
Энергосбережение сетевых интерфейсов: операционная система может переводить сетевой адаптер в режим пониженного энергопотребления при длительных фоновых задачах.
Антивирусный мониторинг: сканирование файлов .bak антивирусом "на лету" на стороне целевого сетевого ресурса блокирует дескриптор файла в момент записи блока данных SQL-сервером.
Сетевые таймауты SMB-протокола: кратковременные перегрузки дисковой подсистемы на целевом хранилище приводят к превышению времени ожидания ответа на операцию записи.

Для устранения ошибки 64 выполним следующие шаги настройки:

В диспетчере устройств Windows на сервере СУБД откроем свойства сетевого адаптера, перейдем на вкладку Управление электропитанием и снимем флажок Разрешить отключение этого устройства для экономии энергии.
В дополнительных свойствах сетевой платы отключим аппаратные функции разгрузки: Large Send Offload (LSO) и TCP Chimney Offload.
В настройках антивирусного ПО на обоих серверах внесем расширение .bak и целевую сетевую директорию в список постоянных исключений.
Проверим права доступа. Обратите внимание: сетевой доступ к целевой папке должен предоставляться не учетной записи пользователя, запускающего задание в Management Studio, а учетной записи службы ядра СУБД (SQL Server Database Engine). Если служба запущена под NT Service\MSSQLSERVER или Local System, необходимо предоставить полные права на сетевую папку и NTFS учетной записи компьютера источника (в формате ДОМЕН\ИМЯ_СЕРВЕРА$) либо перевести службу на доменную сервисную учетную запись.

3. Ошибка 155: 'compression' is not a recognized BACKUP option

При выполнении сценария резервного копирования через SQL Server Agent может возникнуть синтаксическая ошибка: 'compression' is not a recognized BACKUP option. [SQLSTATE 42000] (Error 155).

Разберем причину этого поведения. Возможность сжатия резервных копий зависит от используемой версии и редакции MS SQL Server:

В SQL Server 2008 (без пакета R2) сжатие резервных копий поддерживалось только в редакциях Enterprise и Developer. В редакции Standard эта опция вызывала ошибку 155.
В SQL Server 2008 R2 поддержка сжатия была включена в редакцию Standard, но по-прежнему отсутствует в редакциях Express, Web и Workgroup.

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


SELECT @@VERSION;
SELECT SERVERPROPERTY('Edition') AS Edition, SERVERPROPERTY('ProductLevel') AS ProductLevel;

Если используемая редакция не поддерживает сжатие, необходимо удалить параметр COMPRESSION из команды BACKUP DATABASE.

Если редакция поддерживает сжатие (например, Standard 2008 R2 или Enterprise), рекомендуется включить сжатие по умолчанию на уровне сервера один раз через конфигурационные параметры:


EXEC sp_configure 'backup compression default', 1;
RECONFIGURE;

После включения этой настройки все создаваемые резервные копии будут автоматически сжиматься без необходимости явного указания параметра COMPRESSION в коде T-SQL.

4. Рекомендуемая схема резервного копирования на сетевые хранилища

Прямая запись больших файлов баз данных по сети (SMB/UNC-путь) во время работы СУБД является ненадежной практикой, так как любой кратковременный сетевой сбой прерывает транзакцию создания бэкапа целиком. Наиболее отказоустойчивым решением является двухэтапная схема:

Локальное создание архива: T-SQL скрипт выполняет резервное копирование на быстрый локальный диск сервера (например, D:\Backup\). Это гарантирует максимальную скорость операции и независимость от состояния сети.
Перемещение файла по сети: после завершения транзакции файл перемещается на постоянное сетевое хранилище внешними средствами (скриптом PowerShell или утилитой robocopy с параметрами перезапуска при обрывах /R:3 /W:5 /Z).
Внешняя архивация: если редакция SQL Server не поддерживает встроенное сжатие, локальный файл перед отправкой по сети можно сжать внешним консольным архиватором, что существенно ускорит передачу и сэкономит дисковое пространство.