I had to uninstall SQL Server 2005, because it was configured to be used only in windows authentication mode, and install it again in mixed mode. I had to take a backup of my only database there, and restore it again on installing the sql server back, though the backup was taken successfully but when am trying to restore it, it is giving me an error as
System.Data.SqlClient.SqlError: The media has 2 media families but only 1 are provided. All members must be provided. (Microsoft.SqlServer.Smo)
I am using SQL server management studio, and trying to restore the database by right clicking on the databases folder, selecting restore database option, and then providing a database name, in "destination for restore", and in "source for restore" am selecting from device option and then providing with the path of my .bak file(backup file of the database), but the thing is not working, saying that the restored has failed and giving the above mentioned description for the error.
I suggest that you do not use the SSMS GUI to perform your database RESTORE unless you are familiar with all of the various options and settings. Using the T-SQL RESTORE command you can define explicitly what you are looking to do.
I would suggest that you first verify your database backup file by using the RESTORE VERIFYONLY command.
See SQL Server Books online:
http://msdn.microsoft.com/en-us/library/ms188902.aspx
Is there any chance you backed up to two backup files (ie, striped backup), and you're only specifying one of them in the restore? The restore seems to be complaining that if can't find all the files it needs to start the restore.
if you haven't already tried this: crate a blank database with the exact same name as the data base you're restoring from, with the files at the exact same location. right click the blank database and restore from your backup.
Related
I have two sets of databases for my different testing environments (internal qa and uat). I'm trying to bring qa up to date by restoring it from the latest uat backups. I encountered an issue with the qa DBs getting stuck in "restoring" mode and ended up deleting them, so I'm trying to create a brand new database now by restoring from the UAT backup and changing the name, but it keep failing.
Restore database
Source: device > latestUATbackup.bak
Destination: database > change name from UAT.Web to Dev.Web
Files > check off Relocate all files to folder
Options: Close existing connections to destination database
"Restore of database Dev.Web failed. Access could not be obtained because the database is in use"
I tried taking UAT.Web offline but then it fails with the error "UAT.Web cannot be opened because it is offline"
Why would it matter if the database is in use when I'm using a backup? What do I need to do?
You can't restore a database that is in use because the restore would put it in an inconsistent state. You need to disconnect all active connections (including all SSMS query windows and other applications) from the database in order to restore it. If it already exists make sure to check "Overwrite existing database" on the Options tab of the restore window.
On a side note, up to you but I would recommend not using a '.' in the database name. It can get confusing when using fully qualified object names that include the database.
Go to Options and tick the 'Close existing connections to destination database' option before restoring.
I am testing to see if a SQL Server server based program can also work on AWS Cloud Server with 2016 SQL Server on the Amazon server. In order for me to test it, I need to restore 2 databases.
The first one eventually restored fine once i figured it out...restoring the database from my S3 "bucket" BAK file.
So then I tried to restore the 2nd database, using the same restore stored proceudre, and get this message:
[2017-12-28 02:44:22.320] The file 'D:\rdsdbdata\DATA\smsystemdata.mdf' cannot be overwritten. It is being used by database 'amwsys'.
[2017-12-28 02:44:22.320] File 'sm_system_data' cannot be restored to 'D:\rdsdbdata\DATA\smsystemdata.mdf'. Use WITH MOVE to identify a valid location for the file.
I can't find where to use the WITH MOVE because it won't let me restore it interactively through the Management Studio restore menu; instead I have to give it a stored procedure command:
exec msdb.dbo.rds_restore_database
#restore_db_name='sample99',
#s3_arn_to_restore_from='arn:aws:s3:::lighthouse-chicago/sample999.bak';
And each time it tells me it can't restore it because it's going to overwrite the first database's files.
Much thanks
bill
I think you are stuck in RDS's restriction.
I had the similar problem as you. Multiple restore from one DB instance is impossible at RDS.
Here is RDS's restriction you may encounter.
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Procedural.Importing.html
You can't restore a backup file to the same DB instance that was used
to create the backup file. Instead, restore the backup file to a new
DB instance. Renaming the database is not a workaround for this
limitation.
You can't restore the same backup file to a DB instance multiple
times. That is, you can't restore a backup file to a DB instance that
already contains the database that you are restoring. Renaming the
database is not a workaround for this limitation.
If you are in this case, you can't use .BAK file. To avoid it, you should create DB instance with DML and import table data.
I tried to restore a database but this message showed. How do I restore this database?
Restore of database 'farhangi_db' failed.
(Microsoft.SqlServer.Management.RelationalEngineTasks)
------------------------------ ADDITIONAL INFORMATION:
System.Data.SqlClient.SqlError: BACKUP LOG cannot be performed because
there is no current database backup. (Microsoft.SqlServer.SmoExtended)
Originally, I created a database and then restored the backup file to my new empty database:
Right click on Databases > Restore Database > General : Device: [the
path of back up file] → OK
This was wrong. I shouldn't have first created the database.
Now, instead, I do this:
Right click on Databases > Restore Database > General : Device: [the
path of back up file] → OK
Another cause of this issue is when the Take tail-log backup before restore "Options" setting is enabled.
On the "Options" tab, Disable/uncheck Take tail-log backup before restore before restoring to a database that doesn't yet exist.
Please see below image and apply changes in SqlServer :
first right click on Database --> Task --> Restore --> Select Backup File -->
Finally Apply Change in Options Tab.
Make sure there is a new database.
Make sure you have access to your database (user, password etc).
Make sure there is a backup file with no error in it.
In our case it was due to the Recovery Model on the primary database having been changed after we did the backup in preparation for setting up log shipping.
Ensuring the Recovery Model was set to Full Recovery before doing the backup and setting up log shipping resolved it for us.
You can use following SQL to restore if you've already created database
RESTORE DATABASE [YourDB]
FROM DISK = 'C:\YourDB.bak'
WITH MOVE 'YourDB' TO 'C:\YourDB.mdf',
MOVE 'YourDB_Log' TO 'C:\YourDB.ldf', REPLACE
Another cause for this is if you have the same database restored under a different name.
Delete the existing one and then restoring solved it for me.
I fixed my error on restoring to non-existing DB from SQL 2008 to SQL 2014 by putting a check mark on Relocating to the new SQL2014 folder location.
I just deleted the existing DB that i wanted to override with the backup and restored it from backup and it worked without the error.
I am not sure whether the database backup file, you trying to restore, is coming from the same environment as you trying to restore it onto.
Remember that destination path of .mdf and .ldf files lives with the backup file itself.
If this is not a case, that means the backup file is coming from a different environment from your current hosting one, make sure that .mdf and .ldf file path is the same (exists) as on your machine, relocate these otherwise.
(Mostly a case of restoring db in Docker image)
The way how to do it:
In Databases -> Restore database -> [Files] option -> (Check "Relocate all files to folder" - mostly default path is populated on your hosting environment already)
In case the problem still exists go to Restoration Database page and Check "Restore all files to folder" in "Files" tab This might help
In my case I am restoring a SQL Server 2008 R2 Database to SQL Server 2016
After selecting the file in the General tab, you should go to the Options tab and do 2 things:
You must activate Overwrite existing database
You must deactivate end of record copy
Simply you can use this method:
If you have a database with same name:
WIN+R -> services.msc -> SQL SERVER(MSSQLSERVER) -> Stop
Go to your MySQL Data folder path and delete previews database files
Start sql service
Right click on database and select Restore database
in Files tab change Data file folder and Log file folder
Click on OK to restore your database
my problem was solved with this method
BY...
Click Right Click On Your Database The Press tasks>Back Up and take a back up from your database before restore your database i'm using this way to solve this Problem
I created a database on my local machine and then did a backup called tables.bak of table DataLabTables.
I moved that backup to a remote machine without that table and tried to do a restore but get the following error:
System.Data.SqlClient.SqlError: The operating system returned the
error '5(Access is denied.)' while attempting
'RestoreContainer::ValidateTargetForCreation' on 'c:\Program
Files\Microsoft SQL Server\MSSQL.1\MSSQL\DataLabTables.mdf'.
How do I fix my rights, if that is the problem?
I have just had this issue with SQL Server 2012.
It turns out all I had to do was tick the box marked 'Relocate all files to folder' on the 'Files' section:
(Click to see image full size)
This of course assumes you have the correct version of SQL Server installed.
From the error message, it says there's an error when validating the target (c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DataLabTables.mdf) of your restore operation.
That sounds like:
a) that file already exists (because you've already restored it previously) and is in use by SQL Server
or
b) that directory doesn't exist at all
In your question, you mentioned you created a backup for that table - that's not how SQL Server backups work. Those backups are always the whole database (or at least one or several filegroups from that database).
My hunch is: you've already restored that database previously, and now, upon a second restore, you didn't check the checkbox "Overwrite existing database" in your restore wizard - thus the existing file cannot be overwritten and the restore fails.
The user that's running the restore on your remote server obviously doesn't have access to that directory on the remote server.
C:\program files\.... is a protected directory - normal (non-admin) users don't have access to this directory (and its subdirectories).
Easiest solution: try putting your BAK file somewhere else (e.g. C:\temp) and restore it from there
I was having the same problem. It turned out that my SQL Server and SQL Server Agent services logon as were running under the Network Services account which didn't have write access to perform the restore of the back up.
I changed both of these services to logon on as Local System Account and this fixed the problem.
Recently I faced this issue with SQL 2008 R2 and the below solution worked for me:
1) Create a new database with the same name as the one you are trying to restore
2) While restoring, use the same name you used above and in the options, click the overwrite option
You might give the above a shot if the other solutions don't work.
The backup creator had MSSql version 10 installed, so when he took the backup it also stores the original file path (to be able to restore it in same location), but I had version 11, so it could not find the destination directory.
So I changed the output file directory to C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\, and it was able to restore the database successfully.
Source
I had a similar problem. I tried to restore a 2005 .bak file, and i received exactly the same error. I selected the overwrite option as well to no avail.
my solution was to grant the SQL user access to the directory in question, by going to the folder and editing the access rights through the property screen.
lost a couple of hours to this problem too. got it going though:
"access denied" in my case really did mean "access denied". mssqlstudio's user account on my windows device did NOT have full control of the folder specified in the error message. i gave it full control. access was no longer denied and the restore succeeded.
why was the folder locked up for studio ? who knows ? i got enough questions to deal with as it is without trying to answer more.
I had this issue, I logged in as administrator and it fixed the issue.
Another scenario could be the existence of multiple database paths. First, make note of the path where new databases are currently being stored. So if you create a new empty database and then do Tasks/Restore, make sure that the path the restore is trying to use is the same directory that the empty database was created in. Even if the restore path is legal, you will still get the access denied error if it is not the current path you are working with. Very easy to spot when the path is not legal, much harder to spot when the path is legal, but not the current path.
Sorry because I cannot comment...
I had the same problem. In my case the problem was related to trying to restore in an old sql server folder (that existed on the server). This is due to old sql server backup (i.e. SQL Server 2012 Backup) restored in a new sql server (SQL Server 2014). The real issue is not too different from #marc_s answer. Anyway, I changed only the target folder to the new SQL Server DATA folder.
This may not be the best solution, but I was trying to do the restore at SQL Server 2005, but I changed to SQL Server 2008 and it worked.
Got problem like this. Error caused by enabled compression on SQL Server folders.
Frnds... I had the same issue while restroring database and tried every solution but could nt get resolved. Then i tried to re install SQL 2005 and the problem solved. Actully last time i forgot to check on customize option while instlling SQL.. It comes two times while installing and i checkd it for ones only..
In my case - I had to double check the Backup path of the database from where I was restoring. I had previously restored it from a different path when I did it the first time. I fixed the Backup path to use the backup path I used the first time and it worked!
I ended up making new folders for Data and Logs and it worked properly, must have been a folder/file permission issue.
This also happens if the paths are correct, but the service account is not the owner of the data files (yet it still has enough rights for read/write access). This can occur if the permissions for the files were reset to match the permissions of the folder (of course, while the service was stopped).
The easiest solution in this case is to detach each database and attach it again (because when attaching the owner is changed to be the service account).
Try this:
In the Restore DB wizard window, go to Files tab, Uncheck "Relocate All files to folder" check box then change the restore destination from C: to some other drive. Then proceed with the regular restore process. It will get restored successfully.
I had the same problem but I used sql server 2008 r2, you must check in options and verify the paths where sql going to save the files .mdf and .ldf you must select the path of your sql server installation. I solved my problem with this, I hope it helps you.
Then try moving it to a sub folder under the C:, but verify that the user has full rights on the folder your use.
I want to restore a database from a file (Tasks → Restore → Database; after I select from device and select file) via SQL Server Management Studio.
After that, I get this error:
The operating system returned the error '5(Access is denied.)' while attempting
'RestoreContainer::ValidateTargetForCreation' on 'E:\Program Files\Microsoft SQL
Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\XXXXXX.mdf'.
Msg 3156, Level 16, State 8, Server XXXX, Line 2
How do I fix this problem? Is it a security error?
I recently had this problem. The fix for me was to go to the Files page of the Restore Database dialog and check "Relocate all files to folder".
The account that sql server is running under does not have access to the location where you have the backup file or are trying to restore the database to. You can use SQL Server Configuration Manager to find which account is used to run the SQL Server instance, and then make sure that account has full control over the .BAK file and the folder where the MDF will be restored to.
Well, In my case the solution was quite simple and straight.
I had to change just the value of log On As value.
Steps to Resolve-
Open Sql Server Configuration manager
Right click on SQL Server (MSSQLSERVER)
Go to Properties
change log On As value to LocalSystem
Hoping this will help you too :)
I just ran into this same problem but had a different fix. Essentially I had both SQL Server and SQL Server Express installed on my computer. This wouldn't work when I attempted to restore to SQL Express, but worked correctly when I restored it to SQL Server.
A good solution that can work is go to files > and check the reallocate all files
I tried the above scenario and got the same error 5 (access denied). I did a deep dive and found that the file .bak should have access to the SQL service account. If you are not sure, type services.msc in Start -> Run then check for SQL Service logon account.
Then go to the file, right-click and select Security tab in Properties, then edit to add the new user.
Finally then give full permission to it in order to give full access.
Then from SSMS try to restore the backup.
I was getting the same error while trying to restore SQL 2008 R2 backup db in SQL 2012 DB. I guess the error is due to insufficient permissions to place .mdf and .ldf files in C drive. I tried one simple thing then I succeeded in restoring it successfully.
Try this:
In the Restore DB wizard windows, go to Files tab, change the restore destination from C: to some other drive. Then proceed with the regular restore process. It will definitely get restores successfully!
Hope this helps you too. Cheers :)
There are several causes for this error, I got this error because I checked "Reallocate all files to folder" in the Files tab of Restore Database window but the default path did not exist on my local machine. I had the ldf/mdf files in another folder, once I changed that I was able to restore.
The operating system returned the error '5(access denied.)' when restoring database in sql server can be solved by enabling the Relocate all files to folder in the Files options as follows:
I found this, and it worked for me:
CREATE LOGIN BackupRestoreAdmin WITH PASSWORD='$tr0ngP#$$w0rd'
GO
CREATE USER BackupRestoreAdmin FOR LOGIN BackupRestoreAdmin
GO
EXEC sp_addsrvrolemember 'BackupRestoreAdmin', 'dbcreator'
GO
EXEC sp_addrolemember 'db_owner','BackupRestoreAdmin'
GO
In my case I had to check the box in Overwrite the existing database (WITH REPLACE) under Options tab on Restore Database page.
The reason I was getting this error: because there was already an MDF file present for the database and it was not getting overwritten.
Hope this will help someone.
If you're attaching a database, take a look at the "Databases to attach" grid, and specifically in the Owner column after you've specified your .mdf file. Note the account and give Full Permissions to it for both mdf and ldf files.
I had exactly same problem but my fix was different - my company is encrypting all the files on my machines. After decrypting the file MSSQL did not have any issues to accessing and created the DB. Just right click .bak file -> Properties -> Advanced... -> Encrypt contents to secure data.
this happened to me earlier today, i was a member of the local server's admin group and have unimpeded access, or i thought so. I also ticked the "replace" option, even though there is no such DB in the instance.
Found out that there used to be DB of the same name there, and the MDF and LDF files are still physically located at the data and log folders of the server, but the actual metadata is missing in the sys.databases. the service account of SQL server also can't ovewrwrite the existing files. Found out also that the files' owner is "unknown", i had to change ownership, to the 2 files above so that it is now owned by the local server's admin group, then renamed it.
Then finally, it worked.
The account does not have access to the location for backup file.
Take the following steps to access the SQL Server Configuration Manager via Computer Manager easily
Click the Windows key + R to open the Run window.
Type compmgmt.msc in the Open: box.
Click OK.
Expand Services and Applications.
Expand SQL Server Configuration Manager.
Change User Account in Log On As tab .
Now you can Restore Data Base easily
The fix for me was to go into Options when trying to Restore the database and change the path to the new path.
Here is the screenshot
I encountered the same problem, but my setup is a bit different.
I run my database in a linux docker container
sqlserver management tool in Windows.
What I did was:
sudo docker exec -u root -it sqlserver /bin/bash
This enters the docker container as a root user.
Then:
chmod 777 /path/to/file.bak
777 gives read, write & execute permissions to the file for any group, user