Tail log backup message warning before restoring a backup - sql-server

SSMS 2012
Production server
Production database has Full recovery option.
I want to take a copy of this and restore on to same server with different name.
So I have taken a backup and choose restore but there is a message in the top left corner of the dialog which reads:
a tail-log backup of the source database will be taken...
Additionally, at this point I would rename the destination database, make sure that the rename has renamed the mdf and ldf files and that would be good to go. In this case it hasn't renamed the files so it looks like I will have to do that manually so as not to overwrite the prod database.
I haven't dealt with full recovery databases before. So questions:
What does the tail-log message mean and what are the implications?
Why did the destination database Rename not rename the mdf and ldf files - that's pretty dangerous huh?

What does the tail-log message mean and what are the implications?
Tailog backup message translates to "there is some transaction log generated after your last log backup,so please backup this log so that you can restore to any point in time until this backup"
Why did the destination database Rename not rename the mdf and ldf files - that's pretty dangerous huh?
backup copies only the files,it won't rename them and i don't see why this is dangerous..
I see you trying to restore to the same instance with different name,so tail log backup is not required,since you tried to overwrite the existing database might be the reason for showing tail log backup message

Related

Script to restore SQL Server database with multiple BAK files

I am trying to come up with a script to dynamically do 'Restore Database' in SQL Server 2019 with multiple BAK files that are located in one folder on a daily basis.
I will do the manual full backup first, and this task will be scheduled to run after on a daily basis.
The plan is go thru each BAK files (located in the same folder) sequentially (for example here: 04 --> 12).
There will be another Python script which will wipe out old files, so I am only focusing on execution of Restore database with BAK files that are located in this folder.
What should be the best approach?
I have attached a screenshot that has all BAK files.
I have some T-SQL code here (that I copied from other thread), but I am not sure how to loop over each BAK file sequentially.
And I am not sure whether I have to deal with mdf and ldf files as listed here.
RESTORE DATABASE [Test] FROM DISK ='\\Folder\LOG...04.bak'
WITH
--what ever options... but likely a file move
MOVE 'data_file_1' TO 'E:\somefolder\data.mdf',
MOVE 'db_log' TO 'E:\somefolder\log.ldf',
REPLACE, --overwrites the database
RECOVERY --sets the DB to READ/WRITE. Use NORECOVERY if you need to restore
logs / differentials
GO
RESTORE LOG Test
FROM '\\Folder\Log...04.bak' --assuming this is a log
WITH FILE = 1, --this is the first log
WITH NORECOVERY; --keep in norecovery to restore other logs...
GO

I can not restore my database SQL Server Management Studio can't recognize my .bak files

I'm trying to restore a DB from the class. However, when I try to restore the .bak file, it seems like SSMS doesn't recognize it.
I gave full permissions to the folder which contains the .bak file (it is the default backup folder of ms SQL studio).
Steps I've taken to restore the .bak file:
Right click on DB -> Restore DB -> From device (selected the .bak file location) -> To Database (selected the DB destination)
Like here:
C:\Program Files (x86)\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\Backup
The DB is not corrupt I checked 2 other DB same result so I have no idea what is the problem
Here images:
I can not see the DB and I have almost the latest version of MS SQL studio so I can not understand what is going on here and why I can not restore DBs
I checked here:
restore database in ssms 2017 selected bak file in device option and showing nothing in Backup sets to restore option and disable Ok button too
and here:
SQL Server Management Studio can't recognize .bak file
https://www.youtube.com/watch?v=U0FpXwQfBaU
It should be easy and simple like the video above but like I said above something is wrong here and I do not know what is it.
Image of my SQL version
Once you (i mean the service account) got full permissions on the folder where the .bak file sitting and file not corrupted you should be able to restore without any issue, but there are times things fail in GUI and work perfectly with command line. not sure the issue might be exists one of the fix of SSMS release notes
However, you probably want to try following:
Verify the backup file - it does the verification of backup file and detects any error/corruption within backup file
RESTORE VERIFYONLY FROM DISK = 'C:\YourbackupLocation\DbName.bak';
Read the header - it returns information of backup file i.e. DB Version, appended backup files, LSN info and database recovery model etc..
RESTORE HEADERONLY FROM DISK = 'C:\YourbackupLocation\DbName.bak';
Get list of file names from backup - This will be helpful if the file location is different from the source server from where the backup was created
RESTORE FILELISTONLY FROM DISK = 'C:\YourbackupLocation\DbName.bak' ;
Restore backup - actual restore via T-SQL
RESTORE Backup DBName FROM DISK = 'C:\YourbackupLocation\DbName.bak' with replace, recovery, stats;
To relocate files
RESTORE Backup DBName FROM DISK = 'C:\YourbackupLocation\DbName.bak'
with replace, recovery, stats
--- Get the logical name from the result of "RESTORE FILELISTONLY" command
move 'DBName' to 'C:\NewLocation\DBName.mdf',
move 'DBName_Log' to 'C:\NewLocation\DBName_log.ldf' ;

Database restore is missing tables

I am using SSMS 2017 and attempting to restore a SQL Server 2016 backup (.bak) file to a new database (the data file and log file names in the original backup are different from the new database I am restoring to), so for example, db1.bak is being used to create a new database called db2 through a restore operation.
After the restore completes, all stored procedures and views are present, but none of the tables are there.
These are the steps I've taken in SSMS to perform the restore:
Right click the Databases folder
Select "Restore Database"
Under the General Page: For "Source" I choose Device and select the db1.bak file, and for "Destination" I enter the name of the new database to be created from the backup (db2)
Under the Files Page I select Relocate all files to folder (both Data and Log folder paths have been pre-populated with the correct names) as have the Logical File Name and the Restore As paths.
Under the Options Page I either select nothing or select Overwrite the existing database (WITH REPLACE).
Once the restore completes "successfully" I expand the newly created db2 and click to expand the tables and receive this error message:
What am I doing wrong?
Here is the script:
USE [master]
RESTORE DATABASE [PdsClone] FROM DISK = N'F:\SQLBackups\PDS_backup_2017_12_12_001015_0199267.bak' WITH FILE = 1, MOVE N'PDS_Data' TO N'E:\Program Files\Microsoft SQL Server\MSSQL13.PDS\MSSQL\DATA\PdsClone.mdf', MOVE N'PDS_Log' TO N'E:\Program Files\Microsoft SQL Server\MSSQL13.PDS\MSSQL\DATA\PdsClone_log.ldf', NOUNLOAD, REPLACE, STATS = 5 GO
UPDATE
I had the server group add another disk to that server and moved the SQL backups there, and I was able to successfully complete the restore this morning. I had previously cleaned off most of the backup files, but could it have been a space issue that prevented the tables from showing up in the restore? Every try it indicated success but no tables. They are there now, and I am thankful for your suggestions and help!
Not really an answer to what happened, but perhaps SSMS was doing something a little buggy as #JeroenMostert suggested.

BACKUP LOG cannot be performed because there is no current database backup

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

Why do we need the LDF files along with MDF files?

What would happen if I delete the .ldf file that is in the same folder that my .mdf file?
The LDF file is the transaction log and is required for all SQL server configurations. Depending on the recovery mode, will determine how it is used. However all queries basically get stored here until successfully committed to the database (MDF).
You will not be able to delete it while SQL server service is running. You can detach the database, delete the log file (LDF) and reattach the data file (MDF). However it will just create a new log file. You really should not need to delete it. If it is getting too large you will need to manage it, typically through the backup process.
The database will be marked as suspect on SQL Server restart and inaccessible without some in depth fiddling to recover it.
The LDF is an essential part of the database: you need this file.
You can of course ignore us, and delete it and see for yourself...
As already pointed out, the .LDF file is crucial for the DB and the DB will not be available without one. The .LDF can be deleted only if the DB is offline, or detached or SQL Service is stopped.
Assuming that one of the above 3 scenario was true and you did delete the .LDF file, then the DB would be suspect when SQL server is restarted. If the DB was offline and you try to bring it back online, it will give you an error:
File activation failure. The physical file name "<<filename.ldf>>" may be incorrect.
Msg 945, Level 14, State 2, Line 1
Database '<<DB Name>>' cannot be opened due to inaccessible files or insufficient
memory or disk space. See the SQL Server errorlog for details.
Msg 5069, Level 16, State 1, Line 1
ALTER DATABASE statement failed.
It is quite simple to fix this error, but you will need to delete all the Metadata pertaining to the DB from system files. The easiest way to do that would be to drop the DB. Here is what you will need to do.
Take the DB offline or detach the DB
Make a copy of the .MDF file to your backup directory
Now Drop the DB (You will have to reattach the DB, if you detached, of course)
Copy the .MDF back to the original location
After these steps, run the following:
SP_ATTACH_SINGLE_FILE_DB #dbname='<<DBName>>'
,#physname=N'<<filepath\filename.MDF>>'
This should return you the following:
File activation failure. The physical file name "<<Filepath\filename.ldf>>"
may be incorrect.
New log file '<<Filepath\filename.ldf>>' was created.
That would bring your DB back to an usable state.
The million $$$$ question still remains - why would anyone want to delete the .LDF file???
Raj
The best way to keep the size of .LDF file in check is:
to regularly take transaction log backups at least once a day or
change your recovery model from full to simple ( by default, its full)

Resources