Назад | Перейти на главную страницу

Резервное копирование SQL Ola Hallengren в сетевое расположение не работает

Я установил Решение для обслуживания SQL Server Ола Халленгрен на нескольких серверах SQL Express (с 2008 по 2012 R2) за последние несколько лет. У меня недавно начались проблемы с компонентом сетевого резервного копирования на всех из них, новый. В прошлом у меня это работало на нескольких серверах, поэтому я знаю, что оно может работать, но я не могу понять, что мешает ему работать сейчас. Интересно, что я не администратор баз данных и почти ничего не знаю о SQL, поэтому я здесь.

Эта проблема

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

sqlcmd -E -S SERVER\INSTANCE -d master -Q "EXECUTE dbo.DatabaseBackup @Databases = 'USER_DATABASES', @Directory = '\\techstore1.domain.local\Backups', @BackupType = 'FULL', @Verify = 'Y', @CheckSum = 'Y', @CleanupTime = 14" -b

Некоторое время это работало нормально, но перестало работать около месяца назад. Я настроил его на локальное резервное копирование, затем добавил строку для xcopy его в удаленное место и сценарий на удаленном сервере для очистки старых резервных копий. Не идеальный.

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

Msg 50000, Level 16, State 1, Server SERVER\INSTANCE, Procedure DatabaseBackup, Line 384
The directory \\techstore1.domain.local\Backups does not exist.

Msg 50000, Level 16, State 1, Server SERVER\INSTANCE, Procedure DatabaseBackup, Line 611
The documentation is available at http://ola.hallengren.com/sql-server-backup.html.

Что я наделал

Очевидно, что SQL считает, что сетевого местоположения не существует, поэтому я попытался изо всех сил проверить, что все сетевые компоненты в порядке. Я вытащил новую копию сценария и воссоздал все объекты и задания. Я проверил, работают ли другие скрипты (проверка целостности, обновление статистики и т. Д.). Я создал сценарий, который использует те же учетные данные, что и сценарий резервного копирования, для запуска xcopy локальных резервных копий на целевой сервер, поэтому у меня есть правильные учетные данные общего ресурса / NTFS. Эта учетная запись является учетной записью домена (AD), специально созданной для резервного копирования SQL. Я могу выполнять резервное копирование локально (с этой учетной записью), поэтому у меня есть разрешения для базы данных. Я могу перейти к общему ресурсу в качестве резервной учетной записи с помощью проводника Windows. Я могу вручную скопировать файлы в удаленное место с помощью проводника Windows, используя резервную копию.

У меня такая же проблема и в нескольких других сетях, что и привлекло меня к SF. Я нахожусь в доменах 2008 R2 и 2012, все серверы являются членами домена без каких-либо соответствующих ошибок. Серверы - это машины 2008 R2 и 2012 R2 Standard. Мне кажется, что что-то изменилось на стороне SQL, и я не могу устранить неполадки, чтобы это происходило в 3 разных сетях и на нескольких серверах. Я использовал супер базовые команды - оставив проверку и очистку без работы - и получил ту же ошибку. Я также использовал примеры команд на сайте Олы в качестве теста с теми же результатами. Я пробовал его на новом SQL Server с базовой тестовой базой данных, без любви. Я использовал свой черный пояс в Google в течение нескольких дней с очень неутешительными результатами (может быть, я не знаю, что искать?).

Что я надеюсь получить

Я был бы очень признателен за способ тестирования соединений с общими сетевыми ресурсами внутри командной строки SQL или за некоторые материалы, которые можно было бы прочитать, которые привели бы меня туда. Я не против чтения; Я компетентный системный администратор, который просто не знает этого вопроса. Я прочитал все на сайте Олы, и в любом случае я практически дословно использую примеры команд (а они работали несколько месяцев !?). Я буду работать над этим время от времени и в эти выходные, и любая помощь или направление, которое может предоставить кто-либо, будут очень признательны.

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

"Msg 50000, Level 16, State 1, Procedure DatabaseBackup, Line 395 XXX The directory does not exist."

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

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

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

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

Кроме того, команда, в частности, должна быть SERVER\INSTANCEне SERVER\DATABASE:

sqlcmd -E -S SERVER\INSTANCE -d master -Q "EXECUTE dbo.DatabaseBackup @Databases = 'USER_DATABASES', @Directory = '\\techstore1.domain.local\Backups', @BackupType = 'FULL', @Verify = 'Y', @CheckSum = 'Y', @CleanupTime = 14" -b

(Я не считать это вызовет ошибку, которую вы получаете, но все же.)

Проблема решена. Я создал новое сетевое хранилище, предоставив ему очень открытые разрешения (все: полный доступ), и резервная копия работает в этом месте. Какой бы ни была проблема, она должна быть изолирована от разрешений NTFS / Share на целевом объекте. Я не знаю, почему у нескольких моих клиентов была одна и та же проблема, но это исправление сработало на всех из них. По сути, я воссоздал все свои резервные копии и снова поделился ими. Мы можем никогда не узнать, что изначально пошло не так.

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

Решение: Перезапустите только службу агента SQL - это работает для нас.

Я столкнулся с той же проблемой в последние дни, хранимая процедура dbo.DatabaseBackup не может определить правильные атрибуты файла \ папки, поэтому возникла ошибка о том, что ваше хранилище резервных копий не может быть доступно для пользователя домена, на котором запущены службы агента SQL.

Фрагмент кода хранимой процедуры dbo.DatabaseBackup:

If object_ID(N'tempdb.dbo.#File_Results') is not NULL
    Drop table #File_Results;

CREATE TABLE #File_Results (
File_Exists int,
File_is_a_Directory int,
Parent_Directory_Exists int
)

DECLARE @FileName varchar(255)
SET @FileName='\\DBLIVEBACKUPS\Dump$$'

INSERT INTO #File_Results
EXEC Master.dbo.xp_fileexist @FileName

SELECT * FROM #File_Results

Мы получаем правильные параметры для разных сетевых местоположений на одном сервере.

Следующее должно решить эту проблему. Установите пользователя SQL Server И агент SQL Server на обе общий ресурс и папки как Изменить для общего ресурса и Изменить для безопасности.