Как сделать резервную копию баз данных SQL на сетевом ресурсе

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

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

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

SET LocalFolder = C: программные файлы Microsoft SQL Server MSSQL.1MSSQLBackup
SqlCmd -E -Q «Резервное копирование базы данных MyDB на диск =«% LocalFolder% MyDB.bak »»
XCopy «% LocalFolder% MyDB.bak» «\ 192.168.16.55BackupDatabase» / Z / V
DEL «% LocalFolder% MyDB.bak»

Этот скрипт выполняет следующее (построчно):

Устанавливает переменную в локальный каталог резервного копирования SQL.
Создает резервную копию SQL MyDB (используя проверку подлинности Windows) в локальный каталог резервных копий SQL.
Копирует локальный файл резервной копии в сетевой ресурс.
Удаляет локальный файл резервной копии.

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

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

Как правило, когда вы пытаетесь создать резервную копию непосредственно в сетевой папке с помощью такой команды:

SqlCmd -E -Q «Резервное копирование базы данных MyDB на диск =" \ 192.168.16.55BackupDatabasesMyDB.bak "»

Скорее всего, вы получите сообщение об ошибке:

Сообщение 3201, уровень 16, состояние 1, сервер JF, строка 1
Не удается открыть устройство резервного копирования '\ 192.168.16.55BackupDatabasesMyDB.bak'. Ошибка операционной системы 5 (доступ запрещен.).
Сообщение 3013, уровень 16, состояние 1, сервер JF, строка 1
РЕЗЕРВНАЯ БАЗА ДАННЫХ завершается ненормально.

Эта ошибка возникает несмотря на то, что вы выполнили команду резервного копирования SQL с использованием проверки подлинности Windows (ключ -E) и учетной записи Windows в качестве возможности доступа и копирования файлов на общий ресурс через проводник Windows..

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

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

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

Измените свойства службы SQL Server и на вкладке «Вход в систему» настройте службу для запуска в качестве альтернативной учетной записи с правами доступа к сети..

Когда вы нажмете OK, вы получите сообщение о том, что настройки не вступят в силу, пока служба не будет перезапущена.

Перезапустите сервис.

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

Теперь, когда вы запускаете команду для резервного копирования непосредственно в сетевой ресурс:

SqlCmd -E -Q «Резервное копирование базы данных MyDB на диск =" \ 192.168.16.55BackupDatabasesMyDB.bak "»

Вы должны увидеть сообщение об успехе:

Обработано 152 страницы для базы данных «MyDB», файл «MyDB» для файла 1.
Обработано 2 страницы для базы данных «MyDB», файл «MyDB_log» для файла 1.
BACKUP DATABASE успешно обработал 154 страницы за 0,503 секунды (2,493 МБ / с).

Теперь файл резервной копии находится в общей сетевой папке:

Соображения об общих ресурсах сети

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

Сообщение 3201, уровень 16, состояние 1, сервер JF, строка 1
Не удается открыть устройство резервного копирования '\ 192.168.16.55BackupDatabasesMyDB.bak'. Ошибка операционной системы 1326 (Ошибка входа в систему: неизвестное имя пользователя или неверный пароль.).
Сообщение 3013, уровень 16, состояние 1, сервер JF, строка 1
РЕЗЕРВНАЯ БАЗА ДАННЫХ завершается ненормально.

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

Еще одна проблема, о которой следует помнить, - резервное копирование выполняется непосредственно на сетевой ресурс, поэтому любые сбои в сетевом подключении могут привести к сбою резервного копирования. По этой причине вы должны выполнять только резервное копирование в сетевые местоположения, которые являются стабильными (то есть, вероятно, не VPN).

Последствия для безопасности

Как упоминалось ранее, предпочтительнее использовать метод, при котором вы выполняете локальное резервное копирование, а затем копируете в общий сетевой ресурс, поскольку он позволяет запускать службу SQL в качестве учетной записи только с локальным доступом к системе..

Запустив службу в качестве альтернативной учетной записи, вы открываете дверь для потенциальных проблем безопасности. Например, вредоносный сценарий SQL может выполняться под альтернативной учетной записью и атаковать сетевые ресурсы. Кроме того, любые изменения в соответствующей учетной записи (изменение / истечение срока действия пароля или удаление / отключение учетной записи) приведет к сбою службы SQL Server..

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