Erreur de restauration SQL Server - L'accès est refusé

J'ai créé une base de données sur ma machine locale, puis j'ai fait une sauvegarde appelée tables.baktable DataLabTables.

J'ai déplacé cette sauvegarde sur une machine distante sans cette table et j'ai essayé de faire une restauration mais j'ai obtenu l'erreur suivante:

System.Data.SqlClient.SqlError: Le système d'exploitation a renvoyé l'erreur «5 (Accès refusé.)» Lors de la tentative de «RestoreContainer :: ValidateTargetForCreation» sur «c: \ Program Files \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ DataLabTables .mdf '.

Comment corriger mes droits, si tel est le problème?

Je viens d'avoir ce problème avec SQL Server 2012.

Il s'est avéré que tout ce que j'avais à faire était de cocher la case `` Déplacer tous les fichiers dans le dossier '' dans la section `` Fichiers '':

(Cliquez pour voir l'image en taille réelle)

Cela suppose bien sûr que la version correcte de SQL Server est installée.

Le message d'erreur indique qu'il y a une erreur lors de la validation de la cible ( c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DataLabTables.mdf) de votre opération de restauration.

Cela ressemble à:

a) ce fichier existe déjà (car vous l'avez déjà restauré précédemment) et est utilisé par SQL Server

ou

b) ce répertoire n'existe pas du tout

Dans votre question, vous avez mentionné que vous avez créé une sauvegarde pour cette table - ce n'est pas ainsi que fonctionnent les sauvegardes SQL Server. Ces sauvegardes sont toujours la base de données entière (ou au moins un ou plusieurs groupes de fichiers de cette base de données).

Mon intuition est la suivante: vous avez déjà restauré cette base de données auparavant, et maintenant, lors d'une deuxième restauration, vous n'avez pas coché la case "Écraser la base de données existante" dans votre assistant de restauration - ainsi le fichier existant ne peut pas être écrasé et la restauration échoue.

L'utilisateur qui exécute la restauration sur votre serveur distant n'a évidemment pas accès à ce répertoire sur le serveur distant.

C:\program files\.... est un répertoire protégé - les utilisateurs normaux (non administrateurs) n'ont pas accès à ce répertoire (et à ses sous-répertoires).

Solution la plus simple: essayez de placer votre fichier BAK ailleurs (par exemple C:\temp) et restaurez-le à partir de là

J'avais le même problème. Il s'est avéré que mes SQL Serveret SQL Server Agentservices logon asfonctionnaient sous le Network Servicescompte qui n'avait pas d'accès en écriture pour effectuer la restauration de la sauvegarde.

J'ai changé ces deux services pour ouvrir une session en tant que Local System Accountet cela a résolu le problème.

Récemment, j'ai rencontré ce problème avec SQL 2008 R2 et la solution ci-dessous a fonctionné pour moi:

1) Créez une nouvelle base de données avec le même nom que celui que vous essayez de restaurer 2) Lors de la restauration, utilisez le même nom que vous avez utilisé ci-dessus et dans les options, cliquez sur l'option d'écrasement

Vous pouvez essayer ce qui précède si les autres solutions ne fonctionnent pas.

Le créateur de la sauvegarde avait installé la version 10 de MSSql, donc quand il a pris la sauvegarde, il stocke également le chemin du fichier d'origine (pour pouvoir le restaurer au même endroit), mais j'avais la version 11, donc il n'a pas pu trouver le répertoire de destination.

J'ai donc changé le répertoire du fichier de sortie en C: \ Program Files \ Microsoft SQL Server \ MSSQL11.MSSQLSERVER \ MSSQL \ DATA \, et il a pu restaurer la base de données avec succès.

La source

J'avais un problème similaire. J'ai essayé de restaurer un fichier .bak 2005 et j'ai reçu exactement la même erreur. J'ai également sélectionné l'option d'écrasement en vain.

ma solution était d'accorder à l'utilisateur SQL l'accès au répertoire en question, en allant dans le dossier et en éditant les droits d'accès via l'écran des propriétés.

perdu quelques heures à cause de ce problème aussi. mais ça marche:

«accès refusé» dans mon cas signifiait vraiment «accès refusé». Le compte utilisateur de mssqlstudio sur mon appareil Windows n'a PAS le contrôle total du dossier spécifié dans le message d'erreur. je lui ai donné un contrôle total. l'accès n'était plus refusé et la restauration a réussi.

pourquoi le dossier a-t-il été verrouillé pour le studio? qui sait ? J'ai assez de questions à traiter sans essayer de répondre davantage.

J'ai eu ce problème, je me suis connecté en tant qu'administrateur et cela a résolu le problème.

Un autre scénario pourrait être l'existence de plusieurs chemins de base de données. Tout d'abord, notez le chemin où les nouvelles bases de données sont actuellement stockées. Donc, si vous créez une nouvelle base de données vide, puis que vous le faites Tasks/Restore, assurez-vous que le chemin que la restauration essaie d'utiliser est le même répertoire que celui dans lequel la base de données vide a été créée. Même si le chemin de restauration est légal, vous obtiendrez toujours l'accès refusé erreur si ce n'est pas le chemin actuel avec lequel vous travaillez. Très facile à repérer lorsque le chemin n'est pas légal, beaucoup plus difficile à repérer lorsque le chemin est légal, mais pas le chemin actuel.

Désolé car je ne peux pas commenter ...

J'ai eu le même problème. Dans mon cas, le problème était lié à la tentative de restauration dans un ancien dossier de serveur SQL (qui existait sur le serveur). Cela est dû à l'ancienne sauvegarde du serveur SQL (c'est-à-dire SQL Server 2012 Backup) restaurée dans un nouveau serveur SQL (SQL Server 2014). Le vrai problème n'est pas trop différent de la réponse de @marc_s. Quoi qu'il en soit, j'ai changé uniquement le dossier cible vers le nouveau dossier SQL Server DATA.

Ce n'est peut-être pas la meilleure solution, mais j'essayais de faire la restauration à SQL Server 2005, mais j'ai changé pour SQL Server 2008 et cela a fonctionné.

J'ai un problème comme celui-ci. Erreur causée par la compression activée sur les dossiers SQL Server.

Frnds ... J'ai eu le même problème lors de la restauration de la base de données et j'ai essayé toutes les solutions mais je n'ai pas pu être résolu. Ensuite, j'ai essayé de réinstaller SQL 2005 et le problème est résolu. En fait, la dernière fois, j'ai oublié de vérifier l'option de personnalisation lors de l'installation de SQL.

Dans mon cas, j'ai dû vérifier le chemin de sauvegarde de la base de données à partir de laquelle je restaurais. Je l'avais précédemment restauré à partir d'un chemin différent lorsque je l'ai fait la première fois. J'ai corrigé le chemin de sauvegarde pour utiliser le chemin de sauvegarde que j'ai utilisé la première fois et cela a fonctionné!

J'ai fini par créer de nouveaux dossiers pour les données et les journaux et cela a fonctionné correctement, doit avoir été un problème d'autorisation de dossier / fichier.

Cela se produit également si les chemins sont corrects, mais que le compte de service n'est pas le propriétaire des fichiers de données (mais il a encore suffisamment de droits pour l'accès en lecture / écriture). Cela peut se produire si les autorisations pour les fichiers ont été réinitialisées pour correspondre aux autorisations du dossier (bien sûr, pendant que le service était arrêté).

La solution la plus simple dans ce cas est de détacher chaque base de données et de la rattacher (car lors de la connexion, le propriétaire est changé pour être le compte de service).

Essaye ça:

Dans la fenêtre de l'assistant de restauration de la base de données, accédez à l'onglet Fichiers, décochez la case «Déplacer tous les fichiers dans le dossier», puis modifiez la destination de restauration de C: vers un autre lecteur. Continuez ensuite avec le processus de restauration normal. Il sera restauré avec succès.

J'ai eu le même problème mais j'ai utilisé sql server 2008 r2, vous devez vérifier les options et vérifier les chemins où sql va enregistrer les fichiers .mdf et .ldf, vous devez sélectionner le chemin de l'installation de votre serveur sql. J'ai résolu mon problème avec cela, j'espère que cela vous aidera.

Ensuite, essayez de le déplacer vers un sous-dossier sous le C :, mais vérifiez que l'utilisateur a tous les droits sur le dossier que vous utilisez.