We have a database that is backed up weekly in simple mode. Yesterday, we had a crc error corrupt the mdf file and we were unable to save it. I restored the backup from last week, but now we have a gap from the time of the backup to the time of the restore. Since I have the ldf file from that database, is there any way to "replay" that transaction log to fill in the gap?
I have tried reattaching the ldf file to the recovered mdf file, but SQL Server will not allow me to do that. (It just creates a new ldf file with a different name when I reattach the database.)
Any ideas would help. This is a lot of data to lose and although it is not critical data, I'd like to get it back (as well as learn as well as learn how to do it.)
If you follow the instructions from MSDN -How to: Restore to a Point in Time (SQL Server Management Studio) you should be good. I will not reproduce them here as they are quite long. There is also MSDN - How to: Restore a Transaction Log Backup
Related
I am attempting to do a poor mans log shipping, manually. I need to move a rather large database from one host, to a VM in Azure. The database is currently 16Gb, and we need to do the switch over within an hour.
Note that Replication, Mirroring and Log Shipping are not options due to issues we have run into, and this manual process is what I need to try and achieve.
What I am attempting is to do a full backup the database a few weeks before, using striping of the bak files (So that if a copy fail happens, it's not the full 16Gb we need to restart the copy of), and copy those files of the full backup over a period of a few days.
For my full backup, I am trying to span the backup file over 15 files:
BACKUP DATABASE MyProductionDatabase
TO
DISK='E:\BackupTrial\V5_DEV_FULL_01.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_02.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_03.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_04.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_05.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_06.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_07.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_08.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_09.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_10.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_11.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_12.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_13.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_14.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_15.bak'
WITH FORMAT,
MEDIANAME = 'V5_DEV_FullBackup',
MEDIADESCRIPTION = 'Striped media set for V5_DEV database';
GO
Then restore that database on the new VM in Azure (Virtual Machine, with SQL Server on it, as I am not sure I can go direct BAK file to AzureSQL).
And then daily or weekly (The database has low usage), do log file backups and copy those backups to the new host and restore. So basically, manually trying to keep the databases in sync.
On go-live day, do a final log file backup on the current host, copy that final bak file to the new host, and then both DBs should be in sync, with only small daily copies.
Then switch the site to use the new DB.
But I am stuck:
The MS example is:
BACKUP LOG AdventureWorks2012
TO MyAdvWorks_FullRM_log1;
GO
And it says:
This example creates a transaction log backup for the
AdventureWorks2012 database to the previously created named backup
device, MyAdvWorks_FullRM_log1.
I'm unsure what they mean by "previously created backup device". I have numerous filenames, because of the striping. How do I do a log file backup, of my full backup?
There may be other backup processes that go on on this database. Will this cause me issues with the log file backups (Another full backup of the database might clear my transaction log before I get my backup done?) How should my daily log file backup look?
I'm unsure what they mean by "previously created backup device".
This means that in tis example they previously created virtual backup device.
So now instead of using syntax backup...**to disk** =... they use
backup ...to <device_name>
You can completely ignore this and backup log to differen files as all the world do:
BACKUP LOG AdventureWorks2012
TO disk = 'V:\backups\log\AdventureWorks2012_20190918.trn;
I have numerous filenames, because of the striping. How do I do a log file backup, of my full backup?
Log backup is not done "of full backup".
First you create a "base" by taking full backup, and it doesn't matter if you stripe it into many files or not, then you take log backup (log backups generally are pretty small and you don't need to strip)
There may be other backup processes that go on on this database. Will
this cause me issues with the log file backups (Another full backup of
the database might clear my transaction log before I get my backup
done?)
Full backups are not a problem for you as they just create other "bases" from which you can start your restore chain. You will have problems if others take log backups, as it will interrupt log backup chain (it's not full backup to clear the log, log truncation is done only by log backups).
You should talk to those who take these log backups if they can take them with copy_only: Copy-Only Backups (SQL Server)
or if they can leave these backups for you on some disk.
Given the following (hypothetical) scenario, how would one best backup/restore the database.
Daily doing full backups # 12 am.
Hourly doing differentials 1 am, 2am etc
Transaction log backups on the half hours, 130am, 230am etc
I am also storing the active .ldf file on drive X and the .mdf on drive Y.
Also important the master db is on Y.
Lets say hypothetically the Y drive fails at 245am.
I have the full, diffs and transaction logs up until 230am. BUT I also have the .ldf.
In theory I would have to probably reinstall SQL Server. Then I would want to recover that database up until 245am.
I have heard of doing a tail-log backup on a restore operation BUT I don't have the .mdf anymore. So, I would need to create a new database from my full/diff/log backups. After that I'm not sure how to proceed to get that last 15 minutes of transactions.
I hope this is making sense...
Thanks!
Steve.
You are asking,how to take TailLog Backup when you don't have access to MDF files..
This works only if your database is not in BulkLoggedRecovery model or your log doesn't have Bulk logged transactions..This has been covered in depth here: Disaster recovery 101: backing up the tail of the log
Here are the steps in order
Create a dummy database with same names
Delete all files of this dummy database,by bringing it offline
Copy the original database LDF
Bring this database online which will fail..
Now you can take TailLog Backup using below command..
BACKUP LOG dummydb
TO DISK = N'D:\SQLskills\DemoBackups\DBMaint_Log_Tail.bck' WITH INIT, NO_TRUNCATE;
GO
Now since you have all the backups,you can restore to point in time of Failure
Given a SQL Server 2008 .bak file, is there a way to restore the data file only from the .bak file, without the transaction log?
The reason I'm asking is that the transaction log file size of this database is huge - exceeding the disc space I have readily available.
I have no interest in the transaction log, and no interest in any uncompleted transactions. Normally I would simply shrink the log to zero, once I've restored the database. But that doesn't help when I have insufficient disc space to create the log in the first place.
What I need is a way to tell SQL Server to restore only the data from the .bak file, not the transaction log. Is there any way to do that?
Note that I have no control over the generation of the .bak file - it's from an external source. Shrinking the transaction log before generating the .bak file is not an option.
The transaction log is an integral part of the backup. You can't tell SQL Server to ignore the transaction log, because there is no way to let's say restore and shrink the transaction log file at the same time. However, you can take a look at DBA post to hack the process, although it is not recommended at all
Alternatively you could try some third party tools for restoring, particularly virtual restoring process that can save a lot of space and time. Check out ApexSQL Restore, RedGate Virtual Restore, Idera Virtual Database.
Disclaimer: I work for ApexSQL as support engineer
No, the transaction log is required.
Option 1:
An option may be to restore it to a machine that you DO have enough space on. Then on the restored copy change the logging to either bulk logged or simple, shrink the logs, do another backup operation on this new copy and then use that to restore to the target machine with the now much smaller transaction log.
Option 2:
Alternatively, perhaps the contact at the external source could shrink the transaction log before sending it to you (this may not work if the log is large due to a lot of big transactions).
Docs on the command to shrink the log file are available here.
This is really a question for the ServerFault or DBA sites, but the short answer is no, you can only restore the full .bak file (leaving aside 'exotic' scenarios such as filegroup or piecemeal restores). You don't say what "huge" means, but disk space is cheap; if adding more really isn't an option then you need to find an alternative way of getting the data from your external source.
This may not work since you have no control over the generation of the .bak file, but if you could convince your source to detach the database and then send you a copy of the .mdf file directly, you could then attach the .mdf and your server would automatically create a new empty transaction log file.
See sp_detach_db and sp_attach_db (or CREATE DATABASE database_name FOR ATTACH depending on your sql server version).
I know this is an old thread now, but i stumbled across it while I was having transactional log corruption issues, here is how I got around it without any data loss (I did have down time though!)
Here is what I did:--
Stop the sql server instance service
make a copy of the affected database .mdf file and .ldf file (if you have an .ndf file, copy that as well!) - Just to be sure, you can always put these back if it doesn't work for you.
restart the service.
Log into sql management studio and change the database mode to simple, then take a full backup.
Change the database type back again and once again take a full backup, then take a transactional log backup.
Detach the database.
Right click on databases and click on restore, select the database name from the drop down list, select the later full database backup created (not the one taken from the simple mode) and also select the transactional log backup.
Click restore and it should put it all back without any corruption in the log files.
This worked for me with no errors and my backups all worked correctly afterwards and there were no more transactional log errors.
I have a SQL Server 2005 .BAK file (created with a maintenance plan) that I am trying to restore into a different instance of SQL Server 2005.
Regardless of whether I use the UI or RESTORE DATABASE, the restore process seems to halt at 99%. If I use RESTORE VERIFYONLY FROM DISK='mybackup.bak' it reports that my backup is valid.
Interestingly, immediately after I start the restore process, a 43 GB transaction log file appears in my MSSQL\DATA directory. The .BAK file is 60 MB. The system has more than enough free space for this recovery.
Any suggestions on other restore strategies I should try? I'm going to let the restore run overnight and see what happens.
Thanks
If you have a 43Gb transaction log, depending on the speed of your disks, the restore will take a while. What that means is that when you backed up your db, it had a 43Gb log file and it was empty. So when you restore, the SQL Server has to go and allocate 43Gb for the log file, and it has to physically go and zero out 43Gb, and this takes a while.
What I suggest is to wait a while for restore to complete, couple hours maybe, or do a transaction log backup on production, then shrink the trans log file to say 100Mb and then do a backup, and restore from that.
IT is very important to understand recovery models, and backup models used. Dont just slap a db on production and let it run, if you dont manage it, you will end up with big problems.
I'm using SQL Server 2005.
I need to move a database to a new server with minimum downtime.
Currently my option is to take everything offline, perform a backup, copy the backup to the new server, restore the backup and bring everything back online.
The problem here is that the backup file is about 10Gb, therefore, it takes about 5-10 mins to perform this whole operation.
I've heard of people performing a full backup with everything online and then doing a differential backup so there is less to copy over.
I've taken the full backup, copied that to the new server and restored it. I've then taken a differential backup and copied it to the new server.
The problem is, when I try and restore this backup I get the message "The log or differential backup cannot be restored because no files are ready to rollforward."
I have also tried selecting both the full and differential backup but then I get the error "The volume on device 'D:\FullBackup.bak' is not part of a multiple family media set. BACKUP WITH FORMAT can be used to form a new media set."
Does anyone know what I'm doing wrong and what the easiest way of doing this is?
Thanks
It seems you did not set the NORECOVERY option on the full RESTORE.
You need this option to leave all transactions intact so that you can apply the differential backup later.
If you don't set it, the uncommited transactions get rolled back while restoring the full backup, and the last LSN of the database becomes greater than the first LSN of the differential backup.
Another quick way of doing this is to Detach the database, and then copy the underlying .mdf and .ldf files for your DB straight to the DB, then reattach. Time taken to copy a 10GB file will be much less than the Backup, and it acheives the same thing.