Резервное копирование SQL на сетевой ресурс

Иллюстрация: резервное копирование SQL на сетевой ресурс

Быстрые ссылки

Резервное копирование локально и затем копирование на сетевой ресурс
Резервное копирование напрямую на сетевой ресурс

Введение

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

Резервное копирование локально и затем копирование на сетевой ресурс

Предпочтительный и наиболее надёжный способ — сначала создать локальную резервную копию базы, а затем скопировать файл на сетевой ресурс. Такое разделение снижает вероятность неудачи при создании бэкапа: локальная запись обычно надежнее и быстрее.

Пример простого батч-скрипта, выполняющего бэкап и копирование:

SET LocalFolder=C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup
SqlCmd -E -Q "Backup Database MyDB To Disk='%LocalFolder%\MyDB.bak'"
XCopy "%LocalFolder%\MyDB.bak" "\\192.168.16.55\Backup\Databases" /Z /V
DEL "%LocalFolder%\MyDB.bak"

Пояснение по строкам (коротко):

SET — определяет локальную папку для бэкапов.
SqlCmd — создаёт резервную копию базы MyDB в указанный файл.
XCopy — копирует файл бэкапа на сетевой шар с режимами восстановления сети (/Z) и верификацией (/V).
DEL — удаляет локальный файл бэкапа после успешной копии.

Важно: путь UNC должен быть корректным (пример: \192.168.16.55\Backup\Databases). Если у вас в путях пробелы — оборачивайте в кавычки, как в примере.

Преимущества этого подхода:

Минимум проблем при создании бэкапа — операция идёт по локальному диску.
Можно использовать стандартные инструменты копирования и проверки файлов.
Служба SQL Server может работать под локальной системной учётной записью, что уменьшает риск распространения полномочий в сеть.

Ограничения:

Требуется достаточно места на локальном диске для хранения файла бэкапа до копирования.
Дублирование файлов увеличивает временные требования к операции.

Если на локальном диске недостаточно места, переходите к варианту резервного копирования напрямую на сетевой ресурс.

Резервное копирование напрямую на сетевой ресурс

Иногда нужно писать бэкап прямо на сетевой шар, например, когда на локальном диске нет свободного пространства. Команда может выглядеть так:

SqlCmd -E -Q "Backup Database MyDB To Disk='\\192.168.16.55\Backup\Databases\MyDB.bak'"

Однако при попытке использовать такой подход часто возникает ошибка вида:

Msg 3201, Level 16, State 1, Server JF, Line 1
Cannot open backup device '\\192.168.16.55\Backup\Databases\MyDB.bak'. Operating system error 5(Access is denied.).
Msg 3013, Level 16, State 1, Server JF, Line 1
BACKUP DATABASE is terminating abnormally.

Причина ошибки: процесс, выполняющий бэкап, работает в контексте учётной записи, под которой запущена служба SQL Server. По умолчанию Windows службы часто работают под системными аккаунтами (Local System или Network Service). Эти аккаунты либо не имеют сетевых привилегий, либо их сетевой доступ ограничен.

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

Настройка службы SQL Server для доступа к сети

Откройте «Службы» (Services).
Найдите службу SQL Server (обычно SQL Server (MSSQLSERVER) или похожее имя).
Откройте свойства службы и вкладку «Вход в систему» (Log On).
Выберите вариант «This account» (альтернативная учётная запись) и укажите доменную или локальную учётную запись с правом доступа к сетевому шару.
Введите пароль и подтвердите.
После сохранения система предупредит, что изменения вступят в силу после перезапуска службы — перезапустите службу.

Свойства службы SQL Server с вкладкой Вход в систему

После перезапуска службы проверьте учётную запись в списке служб:

Список служб, показывающий учётную запись для SQL Server

Теперь повторите команду бэкапа напрямую на сетевой шар:

SqlCmd -E -Q "Backup Database MyDB To Disk='\\192.168.16.55\Backup\Databases\MyDB.bak'"

Если всё настроено верно, вы увидите сообщение об успешном выполнении:

Processed 152 pages for database 'MyDB', file 'MyDB' on file 1.
Processed 2 pages for database 'MyDB', file 'MyDB_log' on file 1.
BACKUP DATABASE successfully processed 154 pages in 0.503 seconds (2.493 MB/sec).

После этого файл будет доступен в каталоге на сетевом шаре:

Содержимое сетевой папки с файлом бэкапа MyDB.bak

Важные аспекты сетевого бэкапа

Доступ без интерактивного ввода пароля

Команда резервного копирования требует возможности подключения к сетевому шару без интерактивного ввода учётных данных. Это значит, что учётная запись службы SQL Server должна иметь доверенный доступ (trusted connection) к сетевому ресурсу. В противном случае возникает ошибка вида:

Msg 3201, Level 16, State 1, Server JF, Line 1
Cannot open backup device '\\192.168.16.55\Backup\Databases\MyDB.bak'. Operating system error 1326(Logon failure: unknown user name or bad password.).
Msg 3013, Level 16, State 1, Server JF, Line 1
BACKUP DATABASE is terminating abnormally.

Эта ошибка указывает на неправильные учётные данные, либо на отсутствие доверительных отношений между машинами.

Стабильность сети

Резервное копирование напрямую на сетевой ресурс чувствительно к качеству сети. Любой сбой соединения может привести к повреждённому файлу бэкапа или прерыванию операции. Не рекомендуется писать бэкапы через ненадёжные каналы (например, нестабильные VPN-соединения).

Безопасность и привилегии

Запуск службы SQL Server под учётной записью с сетевыми правами увеличивает потенциальную поверхность атаки. Если учётная запись будет скомпрометирована или уязвимость в SQL позволит выполнить вредоносный код — злоумышленник может получить доступ к сетевым ресурсам от имени этой учётной записи.

Рекомендации:

По возможности используйте первый метод (локальный бэкап + копирование).
Ограничьте права учётной записи до минимума, необходимого для записи в целевую папку.
Установите политику смены паролей и мониторинг отказов входа для этой учётной записи.
Документируйте учётные данные и процедуру их обновления, чтобы сервис не перестал стартовать из-за истечения пароля.

Когда прямой бэкап терпит неудачу — распространённые причины

Служба SQL Server работает под Local System/Network Service и не имеет сетевых привилегий.
Указанная учётная запись не имеет прав записи в целевой каталог на шаре.
Неправильный UNC-путь или опечатка в имени хоста/папки.
Сетевая нестабильность или отклики CIFS/SMB прерываются.
Брандмауэр или политика безопасности блокирует доступ между машинами.
Пароль/учётная запись отключена или истёк, поэтому служба не может подключиться.

Альтернативные подходы

Использовать централизованное решение резервного копирования (Backup software) с агентом на сервере SQL. Агент делает локальный бэкап и переносит его по защищённому каналу.
Монтировать удалённый диск как iSCSI-том: тогда SQL будет работать с ним как с локальным диском. Учтите влияние сети на производительность и риск повреждения при обрыве.
Использовать облачные службы хранения с инструментами синхронизации, которые сначала создают локальную копию, а затем загружают её в облако.

Чек-лист ролей (администратор, DBA, сеть)

DBA:

Убедиться в корректности команд бэкапа.
Настроить расписание и тестовое восстановление.
Контролировать размер файлов и свободное место на дисках.

Системный администратор:

Настроить и вести учётную запись для службы SQL Server.
Обеспечить права на целевой шэр.
Мониторить события входа и ошибки службы.

Сетевая команда:

Проверить стабильность и пропускную способность шары.
Настроить сетевые политики и брандмауэры.
Поддерживать доступность хоста с шэром.

План действий при отказе (инцидентный рукопис)

Зафиксировать сообщение об ошибке и время.
Проверить, работает ли служба SQL Server и под какой учётной записью.
Выполнить ручную попытку бэкапа в локальную папку, чтобы исключить проблемы с SQL.
Попробовать подключиться к шару из-под той же учётной записи вручную (psexec или временно войти на сервер под этой учётной записью).
Проверить лог событий Windows и журнал SQL Server.
При необходимости временно переключиться на метод локального бэкапа и копирования.
Если проблема в сети — связаться с сетевой командой и восстановить соединение.
После восстановления выполнить контрольное восстановление базы из созданного бэкапа.

Критерии приёмки

Файл бэкапа успешно создаётся и доступен на целевом ресурсе.
Размер и контрольная сумма файла совпадают с локальной копией (если применимо).
Процесс бэкапа завершился без ошибок в журналах SQL и Windows.
Тестовое восстановление из этого файла прошло успешно на тестовом сервере.

Мини-методология для внедрения

Оцените свободное место на локальном сервере и на целевом шэре.
Выберите стратегию: локальная копия + синхронизация или прямой бэкап.
Настройте учётную запись службы и права доступа (минимальные привилегии).
Автоматизируйте выполнение и мониторинг (email/система оповещений при ошибке).
Регулярно тестируйте восстановление (минимум ежеквартально).

Ментальные модели и эвристики

«Создай локальную копию перед отправкой» — уменьшает влияние сетевых ошибок.
«Принцип наименьших привилегий» — служебная учётная запись должна иметь ровно те права, которые нужны.
«Проверяй восстановление, а не только бэкап» — файл может создаваться, но быть повреждённым.

Таблица рисков и меры смягчения

Риск: Служба не стартует из-за смены пароля учётной записи. Мера: документировать и синхронизировать изменение паролей, использовать управление секретами.
Риск: Повреждённый бэкап из-за прерывания сети. Мера: использовать локальную копию и проверку контрольной суммы.
Риск: Привилегии злоупотреблены. Мера: ограничить права, мониторить использование и вести аудит.

Decision flowchart (Mermaid)

flowchart TD
  A[Начать резервное копирование] --> B{Есть свободное место локально?}
  B -- Да --> C[Сделать локальный бэкап]
  C --> D[Копировать бэкап на сетевой шар]
  D --> E{Копия успешна?}
  E -- Да --> F[Удалить локальную копию 'опционально']
  E -- Нет --> G[Оповестить и оставить локальную копию]
  B -- Нет --> H[Попытаться бэкап напрямую на шар]
  H --> I{Служба SQL имеет доступ к шару?}
  I -- Да --> J[Выполнить прямой бэкап]
  I -- Нет --> K[Настроить учётную запись или выбрать альтернативный метод]
  J --> L{Бэкап успешен?}
  L -- Да --> M[Оповестить об успехе]
  L -- Нет --> N[Откат к локальному бэкапу или повтор попытки]

Примеры тест-кейсов и критерии приёмки

Создать бэкап локально и убедиться, что файл присутствует в локальной папке и на шере после копирования. Критерий: файлы совпадают по размеру и хэшу.
Настроить службу под новой учётной записью и сделать прямой бэкап на шар. Критерий: команда возвращает успех; файл доступен на шаре.
Имитация сбоя сети в процессе копирования — убедиться, что система оповещает и локальная копия сохранена.

Примечания

Для больших баз и медленных сетей рассмотрите инкрементные или дифференциальные бэкапы и стратегию лог-резервов.
Если вы используете кластерные решения или Always On Availability Groups, обратитесь к рекомендациям Microsoft для конкретной архитектуры.

Контрольный список для развёртывания

Оценено доступное локальное пространство
Определён целевой сетевой шар и права доступа
Настроен график бэкапов и уведомления об ошибках
Реализован тестовый прогон восстановления
Документированы учётные записи и процесс смены паролей

Краткое резюме

Рекомендуемый путь — создавать локальную резервную копию, а затем копировать её на сетевой ресурс. Этот подход сочетает высокую надёжность и простоту восстановления. Если локальное место ограничено, можно писать бэкап напрямую на сетевой шар, но это требует корректной настройки учётной записи службы и контроля безопасности. Всегда автоматизируйте оповещения и регулярно проверяйте восстановление из резервных копий.

Важно: Перед изменением учётной записи службы протестируйте доступ вручную и документируйте все изменения, чтобы избежать простоя службы SQL Server.