Помилка відновлення SQL Server - доступ заборонено

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

Я перемістив цю резервну копію на віддалену машину без цієї таблиці і спробував відновити, але отримав таку помилку:

System.Data.SqlClient.SqlError: Операційна система повернула помилку "5 (доступ заборонено) під час спроби" RestoreContainer :: ValidateTargetForCreation "on 'c: \ Program Files \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ DataLabTables .mdf '.

Як я можу виправити свої права, якщо це проблема?

Щойно у мене виникла ця проблема з SQL Server 2012.

Виявляється, все, що мені потрібно було зробити, це позначити прапорець "Перемістити всі файли в папку" в розділі "Файли":

(Клацніть, щоб побачити зображення в повному розмірі)

Звичайно, передбачається, що у вас встановлена ​​правильна версія SQL Server.

З повідомлення про помилку йдеться про помилку під час перевірки цілі ( c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DataLabTables.mdf) операції відновлення.

Це звучить як:

а) цей файл вже існує (тому що ви його вже відновили) і використовується SQL Server

або

б) цей каталог взагалі не існує

У своєму запитанні ви згадали, що створили резервну копію для цієї таблиці - це не так, як працюють резервні копії SQL Server. Ці резервні копії завжди є цілою базою даних (або принаймні однією або декількома групами файлів із цієї бази даних).

Моя передумова: ви вже відновили цю базу даних раніше, і тепер, під час другого відновлення, ви не встановили прапорець "Перезаписати наявну базу даних" у своєму майстрі відновлення - таким чином, існуючий файл не може бути перезаписаний і відновлення не вдалося.

Користувач, який виконує відновлення на віддаленому сервері, очевидно, не має доступу до цього каталогу на віддаленому сервері.

C:\program files\.... це захищений каталог - звичайні користувачі (не адміністратори) не мають доступу до цього каталогу (та його підкаталогів).

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

У мене була така ж проблема. Виявилося, що мої SQL Serverта SQL Server Agentслужби 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 \, і він зміг успішно відновити базу даних.

Джерело

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

моє рішення полягало в наданні користувачеві SQL доступу до відповідного каталогу, перейшовши в папку та редагуючи права доступу через екран властивості.

втратили пару годин і на цю проблему. все-таки все пішло:

У моєму випадку "заборонений доступ" насправді означав "заборонений доступ". Обліковий запис користувача mssqlstudio на моєму пристрої Windows НЕ здійснював повного контролю над папкою, вказаною в повідомленні про помилку. я дав йому повний контроль. у доступі більше не було заборонено, і відновлення вдалося.

чому папка була заблокована для студії? хто знає ? У мене з’явилося достатньо питань для вирішення, як це є, не намагаючись відповісти більше.

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

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

Вибачте, тому що я не можу коментувати ...

У мене була така ж проблема. У моєму випадку проблема була пов’язана із спробою відновлення в старій папці сервера sql (яка існувала на сервері). Це пов’язано зі старими резервними копіями сервера sql (тобто SQL Server 2012 Backup), відновленими на новому сервері sql (SQL Server 2014). Справжнє питання не надто відрізняється від відповіді @marc_s. У будь-якому випадку я змінив лише цільову папку на нову папку DATA SQL Server.

Це може бути не найкращим рішенням, але я намагався зробити відновлення на SQL Server 2005, але я змінив на SQL Server 2008, і це спрацювало.

Отримала подібну проблему. Помилка, викликана увімкненим стисненням у папках SQL Server.

Frnds ... У мене була та сама проблема під час реструктуризації бази даних та намагалась вирішити кожне рішення, але не могла вирішити. Тоді я спробував перевстановити SQL 2005, і проблема була вирішена. Насправді останній раз я забув перевірити параметр налаштування під час встановлення SQL. Він встановлюється два рази під час встановлення, і я перевіряю його лише для тих, хто ..

У моєму випадку - мені довелося двічі перевірити резервний шлях до бази даних, звідки я був відновлений. Раніше я відновлював його з іншого шляху, коли робив це вперше. Я виправив шлях резервного копіювання, щоб використовувати шлях резервного копіювання, який я використав перший раз, і він працював!

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

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

Найпростішим рішенням у цьому випадку є відокремлення кожної бази даних та приєднання її знову (адже при приєднанні власника змінюється обліковий запис служби).

Спробуйте це:

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

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

Потім спробуйте перемістити його в підпапку під C :, але переконайтеся, що користувач має повні права на папку, яку ви використовуєте.