Резервное копирование баз данных SQL обязательно. Мы уже рассмотрели способы легкого резервного копирования всех ваших баз данных SQL-сервера на локальный жесткий диск, но это не защищает от сбоев в работе диска и / или системы. В качестве дополнительного уровня защиты от этого типа катастрофы вы можете копировать или напрямую создавать свои резервные копии на сетевом ресурсе.
Резервное копирование на локальном компьютере, а затем копирование в сетевой ресурс
Предпочтительный и самый прямой способ выполнить эту задачу - просто создать локальную резервную копию базы данных, а затем скопировать соответствующий файл резервной копии в общий сетевой ресурс. Вы можете сделать это, создав пакетный скрипт, который выглядит так:
SET LocalFolder=C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLBackup SqlCmd -E -Q “Backup Database MyDB To Disk=’%LocalFolder%MyDB.bak'” XCopy “%LocalFolder%MyDB.bak” “192.168.16.55BackupDatabases” /Z /V DEL “%LocalFolder%MyDB.bak”
Этот скрипт выполняет следующие строки (строка за строкой):
- Устанавливает переменную в локальный каталог резервного копирования SQL.
-
Создает резервную копию SQL MyDB (используя проверку подлинности Windows) SQL в локальном каталоге резервного копирования SQL.
-
Копирует локальный файл резервной копии в общий сетевой ресурс.
- Удаляет локальный файл резервной копии.
Опять же, это предпочтительный метод, потому что он работает из коробки, и вероятность сбоя резервного копирования минимальна, поскольку резервная копия создается на локальном диске. Однако, если у вас недостаточно места для хранения локальных копий файлов резервных копий, это действие завершится неудачно. В этом случае вам нужно будет добавить дополнительное дисковое пространство или резервное копирование непосредственно в общий сетевой ресурс.
Резервное копирование непосредственно на сетевой ресурс
Как правило, при попытке создать резервную копию непосредственно на сетевой ресурс с помощью команды, например:
SqlCmd -E -Q “Backup Database MyDB To Disk=’192.168.16.55BackupDatabasesMyDB.bak'”
Вероятно, вы, скорее всего, получите ошибку:
Msg 3201, Level 16, State 1, Server JF, Line 1 Cannot open backup device ‘192.168.16.55BackupDatabasesMyDB.bak’. Operating system error 5(Access is denied.). Msg 3013, Level 16, State 1, Server JF, Line 1 BACKUP DATABASE is terminating abnormally.
Эта ошибка возникает, несмотря на то, что вы запустили команду резервного копирования SQL, используя проверку подлинности Windows (ключ -E) и учетную запись Windows, как возможность доступа и копирования файлов на общий ресурс через проводник Windows.
В нашей системе выполняется резервное копирование в сетевой сетевой ресурс, потому что у нас есть служба SQL Server, работающая как локальная система, которая, опять же, не может получить доступ к каким-либо сетевым ресурсам.
Отредактируйте свойства службы SQL Server и на вкладке «Вход в систему» настройте службу для запуска в качестве альтернативной учетной записи с правами доступа к сети.
SqlCmd -E -Q “Backup Database MyDB To Disk=’192.168.16.55BackupDatabasesMyDB.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).
Теперь файл резервной копии находится в каталоге общего доступа к сети:
Вопросы
Важно отметить, что команда резервного копирования ожидает, что сможет напрямую подключиться к сетевому ресурсу без запроса учетных данных. Учетная запись, которую вы настроили для запуска службы SQL Server, должна иметь доверенное соединение с сетевым ресурсом, доступ к которому разрешает соответствующие учетные данные, в противном случае может возникнуть такая ошибка:
Msg 3201, Level 16, State 1, Server JF, Line 1 Cannot open backup device ‘192.168.16.55BackupDatabasesMyDB.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-службу как учетную запись только с локальным доступом к системе.
Запустив службу в качестве альтернативной учетной записи, вы откроете дверь для потенциальных проблем безопасности. Например, вредоносный SQL-скрипт может выполняться под альтернативной учетной записью и атаковать сетевые ресурсы. Кроме того, любые изменения в соответствующей учетной записи (смены пароля / истечения срока действия или удаления / отключения учетной записи) приведут к тому, что служба SQL Server не запустится.
Важно помнить об этих моментах, если вы запускаете экземпляр SQL Server с помощью альтернативной учетной записи. Несмотря на то, что при соблюдении надлежащих мер предосторожности это не показательные пробки, вам следует рассмотреть возможность добавления дополнительного пространства на жестком диске, а затем реализовать локальную резервную копию и копию, чтобы вы могли запускать службу SQL с помощью локальной учетной записи.
