Как решить проблему доступа SQL Server к сетевой папке для резервного копирования и ошибку "Не удается найти указанный файл"?

← На главную

При попытке настроить резервное копирование баз данных SQL Server на сетевой ресурс, многие администраторы сталкиваются с ошибками доступа, такими как "Невозможно открыть устройство резервного копирования... Ошибка операционной системы 2(Не удается найти указанный файл.)" или "Доступ запрещен" (ошибка операционной системы 5). Эти проблемы обычно связаны с неправильной настройкой разрешений для учетной записи службы SQL Server или особенностями работы с UNC-путями.

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

1. Понимание основной причины: права доступа учетной записи службы SQL Server

Основная причина, по которой SQL Server не может получить доступ к сетевой папке, заключается в том, что учетная запись, под которой работает служба SQL Server, не имеет достаточных прав на запись в эту сетевую папку. Служба SQL Server — это системный процесс, который выполняет все операции с базами данных, включая создание резервных копий. Когда мы указываем сетевой путь (UNC-путь), служба SQL Server пытается получить к нему доступ с помощью своих текущих учетных данных.

1.1. Виртуальные учетные записи и их ограничения

По умолчанию служба SQL Server может работать под виртуальной учетной записью, например NT SERVICE\MSSQLSERVER для экземпляра по умолчанию или NT SERVICE\MSSQL$InstanceName для именованного экземпляра. Эти виртуальные учетные записи обладают ограниченными привилегиями и не могут напрямую получать доступ к удаленным сетевым ресурсам. Если ваша служба работает под такой учетной записью, она, скорее всего, не сможет выполнить резервное копирование на сетевую папку.

1.2. Опасность использования учетной записи доменного администратора

В некоторых случаях, как и в исходной ситуации на форуме, администраторы запускают службу SQL Server под учетной записью доменного администратора, пытаясь решить проблему с правами. Однако это является серьезной брешью в безопасности. Если злоумышленник получит доступ к SQL Server (например, через уязвимость в приложении или слабую парольную политику), он сможет использовать привилегии доменного администратора для компрометации всего домена. Мы настоятельно рекомендуем избегать такого подхода.

1.3. Рекомендуемый подход: выделенная доменная учетная запись

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

Права на запуск службы SQL Server на сервере.
Права на запись (минимум) или полный доступ к целевой сетевой папке.

Убедитесь, что учетная запись службы агента SQL Server также настроена правильно, если вы используете планы обслуживания.

2. Настройка разрешений на сетевой папке

Давайте рассмотрим шаги по настройке разрешений для доступа к сетевой папке:

Создайте или выберите доменную учетную запись, под которой будет работать служба SQL Server (например, DOMAIN\SQLServiceAccount).
Измените учетную запись службы SQL Server (и SQL Server Agent) на эту доменную учетную запись через консоль служб Windows или SQL Server Configuration Manager. Обязательно перезапустите службы SQL Server после изменения учетной записи.
На сервере, где находится сетевая папка (в нашем примере \\backup\E$\1c_backup\sql_meor\), предоставьте этой доменной учетной записи права доступа к самой папке (уровень файловой системы NTFS) и к сетевой общей папке (Share Permissions). Учетная запись должна иметь право на "Изменение" или "Полный доступ".

3. Методы резервного копирования на сетевые ресурсы

Теперь рассмотрим, как технически реализовать резервное копирование, учитывая настроенные права.

3.1. Прямое резервное копирование на UNC-путь с использованием T-SQL

Стандартные средства SQL Server Management Studio (SSMS) иногда могут не давать возможности выбрать сетевую папку напрямую при создании устройства резервного копирования, так как отображают только локальные диски. Однако мы можем использовать системную хранимую процедуру sp_addumpdevice для создания логического устройства резервного копирования, указывая UNC-путь к сетевой папке. Затем мы будем использовать это логическое устройство в команде BACKUP DATABASE.

Вот пример кода T-SQL, предложенный одним из участников форума, который демонстрирует этот подход:


USE [master]
GO

-- Проверяем, существует ли логическое устройство 'sql_srvnas', и если да, удаляем его
IF EXISTS (SELECT * FROM master.dbo.sysdevices WHERE name = 'sql_srvnas')
BEGIN
    EXEC master.dbo.sp_dropdevice @logicalname = N'sql_srvnas'
END
GO

-- Создаем новое логическое устройство резервного копирования, указывая UNC-путь
EXEC master.dbo.sp_addumpdevice @devtype = N'disk', @logicalname = N'sql_srvnas', @physicalname = N'\\backup\E$\1c_backup\sql_meor\sql_srvnas.bak'
GO

-- Выполняем резервное копирование базы данных на созданное устройство
BACKUP DATABASE [sql_srvnas] TO [sql_srvnas] WITH NOFORMAT, NOINIT, NAME = N'sql_srvnas-Полная База данных Резервное копирование', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO

Обратите внимание: в примере `BACKUP DATABASE [sql_srvnas] TO [Zup_backup]` было изменено на `BACKUP DATABASE [sql_srvnas] TO [sql_srvnas]` для соответствия логическому имени устройства sql_srvnas, которое мы создали ранее. Этот код сначала удаляет (если существует) и затем создает устройство с логическим именем sql_srvnas, указывая сетевой путь \\backup\E$\1c_backup\sql_meor\sql_srvnas.bak. Затем выполняется команда BACKUP DATABASE, ссылающаяся на это логическое устройство.

3.2. Резервное копирование на локальный диск с последующим копированием на сетевой ресурс

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

Шаг 1: Резервное копирование на локальный диск.
Настройте планы обслуживания SQL Server или используйте команду BACKUP DATABASE для сохранения резервных копий во временную локальную папку на сервере SQL Server (например, C:\SQLBackups). Для этой операции служба SQL Server нуждается только в локальных правах записи.
Шаг 2: Копирование файлов на сетевой ресурс с помощью скрипта.
После успешного создания локальной резервной копии, вы можете использовать внешний скрипт (например, PowerShell-скрипт, CMD-батник) для копирования этих файлов на целевой сетевой ресурс. Этот скрипт может быть запущен по расписанию через Планировщик заданий Windows.

Преимущества этого подхода:
- Высокая производительность: Первичная запись на локальный диск быстрее.
- Повышенная надежность: Локальная копия служит дополнительной страховкой до того, как файл будет скопирован.
- Гибкость в управлении правами: Скрипт может быть запущен под учетной записью, которая имеет права доступа к сетевой папке, независимо от учетной записи службы SQL Server. Это позволяет поддерживать учетную запись SQL Server с минимальными привилегиями, а для копирования использовать отдельную учетную запись.
Автор темы в итоге пришел к аналогичному решению, используя батник: "Решение просто batник писать. После выполнения плана в SQL запустить батник и все летит на сервак бекапов."

Пример простого батника для копирования:
```
@echo off
SET SOURCE_FOLDER="C:\SQLBackups"
SET DEST_FOLDER="\\backup\E$\1c_backup\sql_meor\"
SET LOG_FILE="C:\SQLBackups\copy_log.txt"

echo Копирование резервных копий SQL Server... > %LOG_FILE%
echo Дата и время: %DATE% %TIME% >> %LOG_FILE%

xcopy %SOURCE_FOLDER%\*.bak %DEST_FOLDER% /D /Y /C /R /H /K >> %LOG_FILE% 2>&1

IF %ERRORLEVEL% NEQ 0 (
    echo ОШИБКА: Копирование завершилось с ошибками! >> %LOG_FILE%
) ELSE (
    echo Копирование завершено успешно. >> %LOG_FILE%
)

echo Удаление старых локальных копий... >> %LOG_FILE%
forfiles /p %SOURCE_FOLDER% /s /m *.bak /d -7 /c "cmd /c del @path" >> %LOG_FILE% 2>&1
```
Данный батник копирует файлы `.bak` из локальной папки на сетевой ресурс, а также удаляет локальные копии старше 7 дней. Запускать его следует через Планировщик заданий Windows под учетной записью, имеющей права на чтение из C:\SQLBackups и запись в \\backup\E$\1c_backup\sql_meor\.

3.3. Подключение сетевого диска (с оговорками)

Некоторые пользователи предпочитают подключать сетевой диск к серверу SQL Server (например, как диск Z:) и затем использовать этот диск для резервного копирования. SQL Server тогда будет "видеть" сетевой ресурс как локальный диск.

Шаги:

Подключите сетевой диск на сервере SQL Server с помощью команды net use Z: \\backup\E$\1c_backup /persistent:yes (запустите от имени пользователя, под которым работает служба SQL Server, или укажите явные учетные данные).
Используйте Z:\sql_meor\sql_srvnas.bak в команде BACKUP DATABASE.

Однако автор темы выразил нежелание использовать этот метод: "Не хочется диски сетевые светить. Сервак для бекапов только. Поэтому и не расшаренный вообще." Это связано с потенциальными рисками безопасности, если сетевой диск становится виден всем, или если его подключение требует более высоких привилегий, чем хотелось бы. Также, если диск подключается только для конкретного пользователя, служба SQL Server может его не увидеть, если работает под другой учетной записью.

В некоторых продвинутых сценариях можно использовать xp_cmdshell для временного монтирования сетевого диска непосредственно из SQL Server перед выполнением резервного копирования и размонтирования после. Однако, xp_cmdshell по умолчанию отключен из соображений безопасности и должен быть включен и использоваться с крайней осторожностью.

4. Проверка сетевой доступности и базовые диагностики

Прежде чем углубляться в настройку прав, убедитесь, что сетевой ресурс вообще доступен с сервера SQL Server:

Проверьте сетевое подключение: С сервера SQL Server попробуйте выполнить ping backup (или по IP адресу) и dir \\backup\E$\1c_backup\sql_meor\. Если эти команды не работают, проблема может быть в сети (файрвол, маршрутизация, недоступность сервера).
Проверьте доступ через проводник Windows: Попытайтесь получить доступ к UNC-пути через проводник Windows, используя учетную запись, под которой запускается служба SQL Server (например, войдите на сервер под этой учетной записью или воспользуйтесь функцией "Запуск от имени другого пользователя").
Проверьте конфигурацию SQL Server: Убедитесь, что протоколы TCP/IP и именованные каналы (Named Pipes) включены в SQL Server Configuration Manager для вашего экземпляра SQL Server. Перезапустите службы после любых изменений.

5. Важность проверки восстановимости резервных копий

Независимо от выбранного метода, критически важно регулярно проверять восстановимость созданных резервных копий. Восстанавливайте базу данных из сохраненного файла в тестовую среду, чтобы убедиться, что файл резервной копии не поврежден и может быть успешно использован в случае необходимости. Резервная копия, которую нельзя восстановить, бесполезна.

Выбрав подходящий метод и правильно настроив права доступа, мы можем обеспечить надежное и безопасное резервное копирование баз данных SQL Server на сетевые ресурсы, избегая распространенных ошибок, таких как "Не удается найти указанный файл" или "Доступ запрещен".