Ошибка восстановления SQL Server - доступ запрещен

Я создал базу данных на своем локальном компьютере, а затем сделал резервную копию tables.bakтаблицы DataLabTables.

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

System.Data.SqlClient.SqlError: Операционная система возвратила ошибку «5 (доступ запрещен.)» При попытке «RestoreContainer :: ValidateTargetForCreation» для «c: \ Program Files \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ DataLabTables». .mdf.

Как мне исправить свои права, если в этом проблема?

У меня только что была эта проблема с SQL Server 2012.

Оказывается, все, что мне нужно было сделать, это установить флажок «Переместить все файлы в папку» в разделе «Файлы»:

(Нажмите, чтобы увидеть изображение в полном размере)

Это, конечно, предполагает, что у вас установлена ​​правильная версия SQL Server.

В сообщении об ошибке говорится, что при проверке target ( c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DataLabTables.mdf) вашей операции восстановления произошла ошибка .

Это звучит как:

а) этот файл уже существует (поскольку вы уже восстановили его ранее) и используется SQL Server

или

б) этот каталог вообще не существует

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

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

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

C:\program files\.... является защищенным каталогом - обычные (не администраторы) пользователи не имеют доступа к этому каталогу (и его подкаталогам).

Самое простое решение: попробуйте поместить свой BAK-файл в другое место (например C:\temp) и восстановить его оттуда

У меня была такая же проблема. Оказалось, что my SQL Serverи SQL Server Agentservices logon asработали под Network Servicesучетной записью, у которой не было прав записи для восстановления резервной копии.

Я изменил обе эти службы для входа в систему, Local System Accountи это решило проблему.

Недавно я столкнулся с этой проблемой в SQL 2008 R2, и у меня сработало следующее решение:

1) Создайте новую базу данных с тем же именем, которое вы пытаетесь восстановить. 2) При восстановлении используйте то же имя, которое вы использовали выше, и в опциях выберите опцию перезаписи.

Вы могли бы дать вышеупомянутый шанс, если другие решения не работают.

Создатель резервной копии установил MSSql версии 10, поэтому при создании резервной копии он также сохраняет исходный путь к файлу (чтобы иметь возможность восстановить его в том же месте), но у меня была версия 11, поэтому он не мог найти каталог назначения.

Поэтому я изменил каталог выходного файла на C: \ Program Files \ Microsoft SQL Server \ MSSQL11.MSSQLSERVER \ MSSQL \ DATA \, и он смог успешно восстановить базу данных.

Источник

У меня была похожая проблема. Я попытался восстановить файл 2005.bak, и я получил точно такую ​​же ошибку. Я выбрал вариант перезаписи, но безрезультатно.

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

потерял пару часов на эту проблему тоже. получил это, хотя:

«Отказано в доступе» в моем случае действительно означало «отказано в доступе». Учетная запись пользователя mssqlstudio на моем устройстве Windows НЕ имела полного контроля над папкой, указанной в сообщении об ошибке. Я дал ему полный контроль. доступ больше не был запрещен, и восстановление прошло успешно.

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

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

Другим сценарием может быть существование нескольких путей к базе данных. Во-первых, запишите путь, по которому в настоящее время хранятся новые базы данных. Поэтому, если вы создаете новую пустую базу данных и затем делаете это Tasks/Restore, убедитесь, что путь, который пытается использовать восстановление, совпадает с каталогом, в котором была создана пустая база данных. Даже если путь восстановления допустим, вы все равно получите отказ в доступе. ошибка, если это не текущий путь, с которым вы работаете. Очень легко определить, когда путь не является законным, гораздо труднее обнаружить, когда путь является законным, но не текущий путь.

Извините, потому что я не могу комментировать ...

У меня такая же проблема. В моем случае проблема была связана с попыткой восстановления в старой папке SQL Server (которая существовала на сервере). Это связано с тем, что на новом сервере sql (SQL Server 2014) восстановлена ​​старая резервная копия сервера SQL Server (т. Е. Резервная копия SQL Server 2012). Реальная проблема не слишком отличается от ответа @marc_s. Во всяком случае, я изменил только целевую папку на новую папку данных SQL Server.

Возможно, это не лучшее решение, но я пытался выполнить восстановление в SQL Server 2005, но я перешел на SQL Server 2008, и это сработало.

Есть проблема, как это. Ошибка, вызванная включенным сжатием в папках SQL Server.

Друзья ... У меня была такая же проблема при восстановлении базы данных, и я испробовал каждое решение, но не смог решить. Затем я попытался переустановить SQL 2005 и проблема решена. На самом деле в прошлый раз я забыл проверить опцию настройки при установке SQL .. При установке это происходит два раза, и я проверил это только для тех, кто ...

В моем случае - мне пришлось дважды проверить путь к резервной копии базы данных, откуда я ее восстанавливал. Я ранее восстановил это с другого пути, когда я сделал это в первый раз. Я исправил путь резервного копирования, чтобы использовать путь резервного копирования, который я использовал в первый раз, и он работал!

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

Это также происходит, если пути правильные, но учетная запись службы не является владельцем файлов данных (хотя у нее все еще достаточно прав для чтения / записи). Это может произойти, если разрешения для файлов были сброшены, чтобы соответствовать разрешениям папки (конечно, пока служба была остановлена).

Самым простым решением в этом случае является отключение каждой базы данных и ее повторное присоединение (поскольку при подключении владелец изменяется на учетную запись службы).

Попробуй это:

В окне мастера восстановления БД перейдите на вкладку «Файлы», снимите флажок «Переместить все файлы в папку» и измените место назначения восстановления с C: на другой диск. Затем продолжите обычный процесс восстановления. Он будет успешно восстановлен.

У меня была такая же проблема, но я использовал sql server 2008 r2, вы должны проверить опции и проверить пути, по которым sql собирается сохранять файлы .mdf и .ldf, вы должны выбрать путь установки вашего сервера sql. Я решил свою проблему с этим, я надеюсь, что это поможет вам.

Затем попробуйте переместить его в подпапку в C:, но убедитесь, что у пользователя есть полные права на папку, которую вы используете.