При настройке планов обслуживания или выполнении ручного резервного копирования баз данных MS SQL Server администраторы часто сталкиваются с ситуацией, когда сервер отказывается принимать сетевой путь в качестве устройства резервного копирования. Особенно остро эта проблема проявляется при попытке использовать скрытые административные ресурсы, такие как \\server\E$. Система выдает ошибку: «Невозможно открыть устройство резервного копирования. Ошибка операционной системы 2 (Не удается найти указанный файл)».
В этой статье мы подробно разберем, почему возникает эта ошибка, как правильно настроить права доступа и какие существуют альтернативные способы автоматизации бэкапов на удаленные хранилища.
Проанализируем причину, по которой классический UNC-путь с символом доллара вызывает затруднения. Административные общие ресурсы (Administrative Shares) создаются операционной системой Windows автоматически для удаленного управления. Однако доступ к ним жестко ограничен на уровне безопасности ядра.
Рассмотрим основные факторы влияния:
sqlservr.exe может работать под другой учетной записью (например, NT Service\MSSQLSERVER или локальной системной записью).Самый правильный и стабильный метод — отказаться от использования скрытых шар E$ в пользу обычных сетевых папок. Выясним, как это сделать правильно по шагам:
SQL_Backups.Network Service, необходимо добавить компьютерную учетную запись сервера (например, DOMAIN\SERVERNAME$).\\backup-srv\SQL_Backups\mybase.bak.Важный момент: Если вы используете SQL Server Agent для выполнения планов обслуживания, убедитесь, что именно его служба также запущена под учетной записью, имеющей доступ к сети. Для настройки регламентных заданий сервера можно использовать руководство по настройке регламентных операций в MS SQL Server.
Рассмотрим ситуацию, когда мы не можем или не хотим менять учетную запись всей службы SQL Server, но нам нужно получить доступ к конкретной сетевой папке. В SQL Server предусмотрен механизм CREDENTIAL.
Проанализируем пример кода для создания таких данных:
-- Создаем учетные данные для доступа к сетевому ресурсу
CREATE CREDENTIAL [\\backup-srv\SQL_Backups]
WITH IDENTITY = 'DOMAIN\BackupUser',
SECRET = 'YourStrongPassword';
GO
После создания учетных данных SQL Server будет использовать указанного пользователя BackupUser для авторизации при попытке обращения к пути \\backup-srv\SQL_Backups. Это позволяет соблюдать принципы безопасности, не давая службе SQL Server избыточных прав во всем домене.
Иногда сетевое соединение может быть нестабильным, или политики безопасности запрещают SQL-серверу «ходить» по сети напрямую. В этом случае мы можем применить надежную схему с использованием командных файлов (bat-скриптов). Именно это решение часто выбирают системные администраторы для критически важных баз.
Разберем алгоритм совместной работы SQL и скриптов:
D:\LocalBackups\). Это гарантирует, что бэкап будет создан максимально быстро и без сетевых задержек.copy_backups.bat, который будет переносить файлы на удаленный сервер.Пример содержимого батника для копирования:
@echo off
set source=D:\LocalBackups
set destination=\\backup-srv\E$\1c_backup\sql_meor
set log=D:\LocalBackups\copy_log.txt
echo %date% %time% Начало копирования >> %log%
xcopy "%source%\*.bak" "%destination%\" /Y /D /I >> %log%
if %errorlevel% equ 0 (
echo %date% %time% Копирование завершено успешно >> %log%
del /Q "%source%\*.bak"
) else (
echo %date% %time% ОШИБКА КОПИРОВАНИЯ! Код ошибки: %errorlevel% >> %log%
)
Такой подход позволяет изолировать процесс создания бэкапа от процесса его передачи в хранилище. Если сеть временно недоступна, файл останется на локальном диске и будет скопирован при следующем запуске. Для комплексной автоматизации создания локальных копий и их ротации можно использовать скрипты для автоматизации архивации и сжатия баз данных SQL Server.
Посмотрим на ситуацию с подключенными дисками (например, диск Z:, который смотрит на шару). Многие пытаются указать в SQL путь Z:\Backup.bak. Это не будет работать в 99% случаев.
Причина в том, что подключенные диски создаются в пользовательской сессии (Session 1, 2 и т.д.), а службы Windows работают в изолированной «Сессии 0». Служба просто не знает о существовании диска Z:. Если вы все же хотите использовать этот метод, диск нужно подключать через xp_cmdshell непосредственно из-под SQL Server, но это крайне не рекомендуется из-за дыр в безопасности.
Выясним еще одну неочевидную причину ошибок при записи бэкапов на сетевые ресурсы. SQL Server при создании бэкапа может пытаться использовать механизм Instant File Initialization (мгновенная инициализация файлов). Для работы этого механизма у учетной записи службы SQL Server в локальных политиках безопасности сервера должно быть право Perform volume maintenance tasks (Выполнение задач по обслуживанию томов).
Чтобы проверить это:
secpol.msc (Локальная политика безопасности).Это право особенно важно при работе с сетевыми хранилищами, так как оно позволяет избежать «зануления» файлов большого объема, что значительно снижает нагрузку на сеть и предотвращает тайм-ауты при создании многогигабайтных архивов.
Подводя итог нашему анализу, сформулируем золотые правила бэкапа SQL на сеть: