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

Обновлено: 04.07.2024

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

Термины и определения

резервный диск
Жесткий диск или другой дисковый носитель, содержащий один или несколько файлов резервных копий. Файл резервной копии — это обычный файл операционной системы.

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

физическое устройство резервного копирования
Либо ленточный накопитель, либо файл на диске, предоставляемый операционной системой. Резервную копию можно записать на от 1 до 64 устройств резервного копирования. Если для резервного копирования требуется несколько устройств резервного копирования, все устройства должны соответствовать одному типу устройств (диск или лента).

Резервные копии SQL Server можно также записывать в службу хранилища BLOB-объектов Azure в дополнение к диску или ленте.

Использование дисковых устройств резервного копирования

Если файл на диске заполняется, когда операция резервного копирования добавляет резервную копию к набору носителей, операция резервного копирования завершается ошибкой. Максимальный размер файла резервной копии определяется свободным дисковым пространством, доступным на дисковом устройстве; поэтому подходящий размер дискового устройства резервного копирования зависит от размера ваших резервных копий.

Дисковым устройством резервного копирования может быть простое дисковое устройство, например диск ATA. В качестве альтернативы вы можете использовать диск с возможностью горячей замены, который позволит вам прозрачно заменить полный диск на диске пустым диском. Резервный диск может быть локальным диском на сервере или удаленным диском, который является общим сетевым ресурсом. Сведения о том, как использовать удаленный диск, см. в разделе «Резервное копирование файла на сетевом ресурсе» далее в этом разделе.

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

ВАЖНО! Мы рекомендуем, чтобы резервный диск отличался от диска данных базы данных и журналов. Это необходимо для обеспечения доступа к резервным копиям в случае сбоя диска данных или журнала.

Если файлы базы данных и файлы резервных копий находятся на одном устройстве, а устройство выходит из строя, база данных и резервные копии будут недоступны. . Кроме того, размещение базы данных и файлов резервных копий на отдельных устройствах оптимизирует производительность ввода-вывода как для производственного использования базы данных, так и для записи резервных копий.

Укажите файл резервной копии, используя его физическое имя (Transact-SQL)

Основной синтаксис BACKUP для указания файла резервной копии с использованием имени физического устройства:

РЕЗЕРВНАЯ БАЗА ДАННЫХ имя_базы_данных

НА ДИСК = < 'имя_устройства_резервной_копии' | @physical_backup_device_name_var >

Основной синтаксис для указания физического дискового устройства в инструкции RESTORE:

FROM DISK = < 'имя_устройства_резервной_копии' | @physical_backup_device_name_var >

Укажите путь к файлу резервной копии диска

При указании файла резервной копии необходимо указать полный путь и имя файла. Если вы указываете только имя файла или относительный путь при резервном копировании в файл, файл резервной копии помещается в каталог резервного копирования по умолчанию. Каталог резервного копирования по умолчанию — C:\Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\Backup, где n — номер экземпляра сервера. Таким образом, для экземпляра сервера по умолчанию каталог резервного копирования по умолчанию: C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Backup.

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

ПРИМЕЧАНИЕ. Расположение по умолчанию хранится в разделе реестра BackupDirectory в разделе HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.n\MSSQLServer.

Резервное копирование в общий сетевой файл

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

Для резервного копирования на сетевой диск, когда SQL Server работает в учетной записи пользователя домена, общий диск должен быть сопоставлен как сетевой диск в сеансе, где работает SQL Server. Если вы запустите Sqlservr.exe из командной строки, SQL Server увидит все сетевые диски, которые вы сопоставили во время сеанса входа в систему.

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

Вы можете подключиться к учетной записи сетевой службы, используя учетную запись компьютера вместо пользователя домена. Чтобы включить резервное копирование с определенных компьютеров на общий диск, предоставьте доступ к учетным записям компьютеров. Пока процесс Sqlservr.exe, записывающий резервную копию, имеет доступ, не имеет значения, имеет ли доступ пользователь, отправляющий команду BACKUP.

ВАЖНО! Резервное копирование данных по сети может быть связано с сетевыми ошибками; поэтому мы рекомендуем при использовании удаленного диска проверять операцию резервного копирования после ее завершения. Дополнительные сведения см. в разделе ВОССТАНОВЛЕНИЕ С ПРОВЕРКОЙ ТОЛЬКО (Transact-SQL).

Укажите имя в формате UNC

Чтобы указать общий сетевой ресурс в команде резервного копирования или восстановления, используйте полное универсальное соглашение об именах (UNC) имени файла для устройства резервного копирования. Имя UNC имеет вид \\Имя системы\Имя общего ресурса\Путь\Имя файла.

Использование ленточных устройств

ПРИМЕЧАНИЕ. Поддержка ленточных устройств резервного копирования будет удалена в будущей версии SQL Server. Избегайте использования этой функции в новых разработках и планируйте модифицировать приложения, которые в настоящее время используют эту функцию.

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

При использовании ленточного накопителя операция резервного копирования может заполнить одну ленту и продолжиться на другой ленте. Каждая лента содержит заголовок носителя. Первый используемый носитель называется исходной лентой. Каждая последующая лента называется лентой-продолжением и имеет порядковый номер носителя, который на единицу выше, чем у предыдущей ленты. Например, набор носителей, связанный с четырьмя лентопротяжными устройствами, содержит как минимум четыре исходные ленты (и, если база данных не подходит, четыре серии лент-продолжений). При добавлении набора резервных копий необходимо подключить последнюю ленту в серии. Если последняя лента не смонтирована, компонент Database Engine просматривает до конца смонтированной ленты, а затем требует, чтобы вы заменили ленту. В этот момент смонтируйте последнюю ленту.

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

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

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

Укажите резервную ленту, используя ее физическое имя (Transact-SQL)

Основной синтаксис BACKUP для указания резервной ленты с использованием имени физического устройства стримера:

TO TAPE = < 'имя_физического_резервного_устройства' | @physical_backup_device_name_var >

Основной синтаксис для указания физического ленточного устройства в инструкции RESTORE:

FROM TAPE = < 'имя_устройства_резервной_копии' | @physical_backup_device_name_var >

Параметры резервного копирования и восстановления для конкретных лент (Transact-SQL)

Для облегчения управления лентами оператор BACKUP предоставляет следующие параметры для конкретных лент:

Вы можете управлять автоматической выгрузкой резервной ленты из ленточного накопителя после операции резервного копирования или восстановления. UNLOAD/NOUNLOAD – это параметр сеанса, который сохраняется на протяжении всего сеанса или до тех пор, пока он не будет сброшен путем указания альтернативы.

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

ПРИМЕЧАНИЕ. Дополнительные сведения о синтаксисе и аргументах BACKUP см. в разделе BACKUP (Transact-SQL). Дополнительные сведения о синтаксисе и аргументах RESTORE см. в разделах RESTORE (Transact-SQL) и RESTORE Arguments (Transact-SQL) соответственно.

Управление открытыми лентами

Чтобы просмотреть список открытых ленточных устройств и состояние запросов на подключение, запросите представление динамического управления sys.dm_io_backup_tapes. В этом представлении показаны все открытые ленты.К ним относятся используемые ленты, которые временно простаивают, ожидая следующей операции BACKUP или RESTORE.

Если лента была случайно оставлена открытой, самый быстрый способ освободить ее — использовать следующую команду: RESTORE REWINDONLY FROM TAPE =имя_устройства_резервного_копирования. Дополнительные сведения см. в разделе ВОССТАНОВЛЕНИЕ ТОЛЬКО ПОВТОРНО (Transact-SQL).

Использование службы хранилища BLOB-объектов Azure

Резервные копии SQL Server можно записывать в службу хранилища BLOB-объектов Azure. Дополнительные сведения об использовании службы хранилища BLOB-объектов Azure для резервных копий см. в разделе Резервное копирование и восстановление SQL Server с помощью службы хранилища BLOB-объектов Microsoft Azure.

Использовать логическое устройство резервного копирования

логическое устройство резервного копирования – это необязательное определяемое пользователем имя, указывающее на конкретное физическое устройство резервного копирования (дисковый файл или ленточный накопитель). Логическое устройство резервного копирования позволяет использовать косвенное обращение к соответствующему физическому устройству резервного копирования.

Определение логического устройства резервного копирования включает присвоение логического имени физическому устройству. Например, логическое устройство AdventureWorksBackups можно определить так, чтобы оно указывало на файл Z:\SQLServerBackups\AdventureWorks2012.bak или на ленточный накопитель \\.\tape0. Затем команды резервного копирования и восстановления могут указать AdventureWorksBackups в качестве устройства резервного копирования вместо DISK = 'Z:\SQLServerBackups\AdventureWorks2012.bak' или TAPE = '\\.\tape0'.

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

После определения логического устройства резервного копирования в команде BACKUP или RESTORE можно указать логическое устройство резервного копирования вместо физического имени устройства. Например, следующий оператор выполняет резервное копирование базы данных AdventureWorks2012 на логическое устройство резервного копирования AdventureWorksBackups.

ПРИМЕЧАНИЕ. В данной инструкции BACKUP или RESTORE имя логического устройства резервного копирования и соответствующее имя физического устройства резервного копирования взаимозаменяемы.

Одним из преимуществ использования логического устройства резервного копирования является то, что его проще использовать, чем длинный путь. Использование логического устройства резервного копирования может помочь, если вы планируете записывать серию резервных копий по одному и тому же пути или на ленточное устройство. Логические устройства резервного копирования особенно полезны для идентификации ленточных устройств резервного копирования.

Сценарий резервного копирования может быть написан для использования определенного логического устройства резервного копирования. Это позволяет переключаться на новые физические устройства резервного копирования без обновления сценария. Переключение включает следующий процесс:

Удаление исходного логического устройства резервного копирования.

Определение нового логического устройства резервного копирования, которое использует исходное имя логического устройства, но сопоставляется с другим физическим устройством резервного копирования. Логические устройства резервного копирования особенно полезны для идентификации ленточных устройств резервного копирования.

Наборы носителей с зеркальными резервными копиями

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

ПРИМЕЧАНИЕ. Наборы носителей с зеркальными резервными копиями поддерживаются только в SQL Server 2005 Enterprise Edition и более поздних версиях.

Архивация резервных копий SQL Server

Мы рекомендуем использовать утилиту резервного копирования файловой системы для архивирования резервных копий дисков и хранить архивы вне офиса. Использование диска имеет то преимущество, что вы используете сеть для записи архивных резервных копий на внешний диск. Службу хранилища BLOB-объектов Azure можно использовать как вариант архивирования за пределами площадки. Вы можете загрузить резервные копии дисков или напрямую записать резервные копии в службу хранилища BLOB-объектов Azure.

Еще один распространенный подход к архивированию — запись резервных копий SQL Server на локальный резервный диск, их архивирование на ленту, а затем хранение лент вне офиса.

Этот форум перенесен в раздел вопросов и ответов Майкрософт. Посетите Microsoft Q&A, чтобы публиковать новые вопросы.

Отвечает:

Вопрос

Возможно резервное копирование базы данных на локальный диск (C:) в SQL Server 2005. Но когда я попытался сделать резервную копию базы данных на подключенный сетевой диск (N:) на сервере, это не удалось. Вот сообщение:
System.Data.SqlClient.SqlError: Не удается открыть устройство резервного копирования «N:\db.bak». Ошибка операционной системы 3 (Система не может найти указанный путь.). (Майкрософт.SqlServer.Smo)

Сетевой диск N: доступен через проводник Windows. В настоящее время мы выполняем резервное копирование наших рабочих баз данных в центральное место (SAN) на SQL Server 2000.

Как сделать резервную копию базы данных на сетевой диск в SQL Server 2005?
Спасибо,
Тони

Ответы

Думал поделиться этим:

Если вы используете unc, например, \\server\share\mydb.bak, для резервного копирования или восстановления, и он жалуется, что невозможно определить местоположение файла или что не удалось войти в систему, существует простое решение. . Убедитесь, что файл виден с машины с сервером sql. Если это так, но вы все еще получаете ошибку, это может быть только одно - логин, под которым работает служба SQL Server, не имеет доступа к сетевому местоположению. В моем случае я зашел в Панель управления -> Администрирование -> Службы (на сервере). Я нашел службу SQL Server, проверил ее свойства и обнаружил, что она использует учетную запись локального администратора (.\Administrator), которая, очевидно, не имеет доступа к остальной части домена. Я изменил это на пользователя домена, перезапустил службу, и вуаля, пути unc теперь работают нормально.

Надеюсь, это сэкономит кому-то время.

Только что узнал, что мы можем сделать резервную копию базы данных на сетевой адрес, например "\\network_path\db.bak". Это сработало. Но это не сработало для подключенного диска (N:).
Для восстановления на другой тестовый сервер нет графического интерфейса через Management Studio. Все должно быть сделано скриптами SQL. С Management Studio мы не могли просматривать содержимое любого файла резервной копии с удаленного сетевого адреса. В окне запроса мы можем запустить «ВОССТАНОВИТЬ FILELISTONLY FROM DISK = N'\\network_path\db.bak'», чтобы просмотреть его содержимое. Затем запустите «ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ», чтобы восстановить ее в тестовой базе данных.

Все ответы

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

Спасибо, Эйса.
Тогда у нас определенно будут проблемы, когда мы будем использовать SQL 2005 в будущем. Прямо сейчас размер одной из наших производственных баз данных составляет 260 ГБ. С SQL 2005 мы должны создать локальный диск для его резервного копирования. Это может занять несколько часов. Затем нам нужно скопировать файл резервной копии в наше центральное хранилище резервных копий (SAN) вручную. Это займет несколько часов. Затем, если мы хотим восстановить его на тестовом сервере базы данных, мы должны скопировать файл резервной копии на локальный диск этого тестового сервера, поскольку SQL 2005 также не может прочитать файл резервной копии с подключенного сетевого диска. От резервной копии до восстановления на другом тестовом сервере базы данных может пройти от 15 до 24 часов для одной копии. Помимо времени резервного копирования/копирования/восстановления, нам также приходится выделять больше места на диске для каждой дополнительной копии. Производственному серверу требуется 260 ГБ (рабочая база данных) + 260 ГБ (резервная копия). Для центрального хранилища резервных копий требуется 260 ГБ. Тестовому серверу требуется 260 ГБ (файл резервной копии) + 260 ГБ (тестовая база данных). Всего 1300 Гб. Ой!
Возможно, нам придется продолжать использовать SQL Server 2000, так как SQL Server 2000 не вызывает проблем ни на одном подключенном сетевом диске.

Я использую Visual Studio 2005 с vb. Просто попробуйте создать небольшую базу данных на сетевом диске, используя источник привязки и адаптер таблицы ( BindingSource.EndEdit() и TableAdapter.Update ). Он не может прочитать мою базу данных. Я перехожу к сетевому обозревателю -> изменить соединение и в имени файла базы данных введите "\\network_path\database.mdf

Однако я получил следующее сообщение об ошибке:
"Файл\\network_path\database.mdf находится на сетевом пути, который не поддерживается для файлов базы данных.
И попытка прикрепить Ошибка автоматического присвоения имени базе данных для файла \\network_path\database.mdf. База данных с таким именем существует, или указанный файл не может быть открыт, или он находится в общей папке UNC."

Итак, как я могу изменить свой код, чтобы иметь доступ (чтение/запись) к базе данных на сетевом диске? Спасибо

SQL Server не может прикреплять файлы данных, которые находятся не на сервере.

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

< бр />

Джейсон Фолкнер

Джейсон Фолкнер
Сценарист

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

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

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

SET LocalFolder=C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLBackup
SqlCmd -E -Q «Резервное копирование базы данных MyDB на диск = '%LocalFolder%MyDB.bak'»
XCopy «%LocalFolder %MyDB.bak” “\192.168.16.55BackupDatabases” /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
BACKUP DATABASE аварийно завершает работу.

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

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

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

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

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

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

Перезапустите службу.

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

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

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

Обработано 152 страницы для базы данных «MyDB», файл «MyDB» в файле 1.
Обработано 2 страницы для базы данных «MyDB», файл «MyDB_log» в файле 1.
РЕЗЕРВНАЯ БАЗА ДАННЫХ успешно обработано 154 страницы за 0,503 секунды (2,493 МБ/с).

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

Советы по использованию общих сетевых ресурсов

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

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

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

Влияние на безопасность

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

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

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

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

Начните с подключения сетевого диска (необязательно):

Введите путь к сетевому диску и нажмите Далее:

Вам будет предложено ввести учетные данные, сделайте это, затем нажмите "Готово"

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

Однако, если вы перейдете в SSMS и попытаетесь создать резервную копию базы данных через графический интерфейс, вы не сможете увидеть букву диска:

Если вы попытаетесь сделать это с помощью скрипта, вы получите ошибку операционной системы:

Сообщение 3201, уровень 16, состояние 1, строка 1

Не удается открыть устройство резервного копирования Z:\test.bak. Ошибка операционной системы 3(системе не удается найти указанный путь).

Сообщение 3013, уровень 16, состояние 1, строка 1

BACKUP DATABASE аварийно завершает работу.

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

Итак, как мы можем обойти это? С помощью XP_CMDSHELL.

Во-первых, убедитесь, что XP_CMDSHELL включен:

Затем используйте следующую команду, заменив Z: \\mymachine\localvmshare на свой сетевой путь:

EXEC XP_CMDSHELL 'чистое использование Z: \\mymachine\localvmshare'

Теперь диск должен быть подключен. Вы можете проверить правильность сопоставления следующим образом:

EXEC XP_CMDSHELL 'Каталог Z:'

Если вы неправильно наберете путь, вы можете увидеть ошибку, подобную этой:

Произошла системная ошибка 53. Сетевой путь не найден.

Если вы получили эту ошибку, просто исправьте опечатку и повторите команду.

Еще одна ошибка, которую вы можете получить, это:

Введите имя пользователя для «mymachine»:

Операция отменена пользователем.

Если это произойдет, измените инструкцию XP_CMDSHELL следующим образом, где serviceaccount — это пользователь, имеющий разрешение на подключение сетевого диска, а passwordgoes — пароль для учетной записи пользователя:

EXEC XP_CMDSHELL 'net use Z: \\mymachine\localvmshare /user:serviceaccount passwordgoeshere'

Теперь в графическом интерфейсе мы должны увидеть наш недавно подключенный диск в мастере резервного копирования/восстановления:

Если мы повторно запустим наш скрипт для резервного копирования, он будет успешным:

И вот наш резервный файл:

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

Дополнительную информацию о XP_CMDSHELL см. здесь.

Автор: Эйвери Лейн

Привет, меня зовут Эйвери, и я думаю, что компьютеры и математика — это круто. Просмотреть все сообщения Эйвери Лейн

Автор Avery Lane Опубликовано 10 мая 2021 г. 1 июля 2021 г. Категории Все сообщения, Microsoft SQL Server, Советы и рекомендации Теги резервное копирование, сетевой диск, сетевой путь, восстановление, xp_cmdshell

Оставить ответ Отменить ответ

Вы должны войти в систему, чтобы оставить комментарий.

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

Читайте также: