SQL server 2012 - Difference between point in time and complete? - sql-server

So i have read Microsoft etc and am struggling to understand the difference in Point in time recovery and complete recovery (i.e. seems to do the same thing, slightly differently).
I.e. when should i use one as opposed to the other, from what i can see i should always use point in time if i have a full backup model?.

Point in time recovery is where you wanted to restore database to specific time of the date, for example some records accidentally deleted at 3:45PM from database and log backup runs every 30 minutes, this is where you can restore database to 3:45PM using Log backups and STOPAT.
RESTORE DATABASE AdventureWorks FROM DISK = 'C:\AdventureWorks.BAK'
WITH NORECOVERY
GO
RESTORE LOG AdventureWorks FROM DISK = 'C:\AdventureWorks.TRN'
WITH RECOVERY,
STOPAT = 'Mar 01, 2017 03:45:00 PM'
GO
Whereby complete recovery is something you can recover database from backups (full/differential) to the last or specific date/time log backup.

Related

Is there a way to keep on restoring SQL database backups periodically, and meanwhile access the database from another application?

I'm periodically getting backups of an SQL database which I would like to restore in my machine. I'm able to do that with RESTORE fullDB WITH NORECOVERY; RESTORE differentialDB WITH RECOVERY;
However, I need to access the restored database in between, as the interval in which I'm getting the backups can be a few hours.
I tried restoring full backup WITH RECOVERY, but in that case I'm getting exception while restoring differential backup.
NB: It's not just one differential backup, it's real time backups taken every few hours. I'm using C# for executing the operations.
Any help is appreciated to solve the issue. Also, let me know if I'm barking at the wrong tree.
Instead of sending SQL database backups from client as .bak files, should I opt any other way to send the data?
Take a look at the STANDBY option for the RESTORE statement. From the docs:
Specifies a standby file that allows the recovery effects to be undone.
NB - differential backups are based on the last full backup taken. So let's say that you take full backups on Sunday, differential backups every other day of the week and you're restoring every day.
Sunday, you'd restore only the full backup, bringing it online for read by specifying STANDBY with the restore
Monday through Saturday, you'd restore the latest differential backup on top of what you've already restored, again using STANDBY
When Sunday rolls around again, you'd need to restore the new full backup.
That said, you mentioned that you're on SQL Express. The database size limit is 10 Gb. At that size, how long does the restore of the full backup take? Is it worth your time? And even there, it's really "how much time are you saving the robot?" because you've already (presumably) automated the restore.

Why is my SQL Server Differential backup failing sometimes?

I'm having an issue that only happens sometimes where my SQL Server differential backup job fails with an error message similar to
Msg 3035, Sev 16, State 1, Line 1 : Cannot perform a differential backup for database "MyDatabaseName", because a current database backup does not exist. Perform a full database backup by reissuing BACKUP DATABASE, omitting the WITH DIFFERENTIAL option. [SQLSTATE 42000]
Msg 3013, Sev 16, State 1, Line 1 : BACKUP DATABASE is terminating abnormally. [SQLSTATE 42000]
I'm currently using Ola Hallengren's SQL Server Mantenance Solution script for backup's, integrity check's and index maintenance. I've scheduled the backup job's as such:
Full Backup of system databases every day # 1:30 AM
Full Backup of all user databases every week on Monday, Wednesday & Friday # 2:30 AM
Differential Backup of all user databases every week on Sunday, Tuesday, Thursday & Saturday # 2:30 AM
Transaction Log backup or all user databases every 30 minutes
I've also set the cleanup time to 168 hours...which is 7 days.
I know that usually when this error message comes up, it is due to a full backup not being present, or possible the recovery mode on a database being changed. I have checked both of these and neither seems to be the case. I can confirm that my Friday full backup was successful, however my Saturday and Sunday Differentials failed. There have also been no changes to the recovery model, and no manual backup taken through SQL Server.
It's worth noting that this only happens sometimes. Sometimes the differential backups work without a problem and other times they fail.
This server is a VM, and we are using VMWare vSphere/vCenter 6.5. I've talked to my server admin and asked how his backup is running an he told me that we are using Quest AppAssure which leverage VMWare snapshot technology, and that he is backuping the drives every x number of minutes, so it is possible that the time of his backup changes and eventually overlaps with mine.
We looked back at the time that his backups ran on the weekend and they happened within a few minutes before mine started. I'm wondering if this is causing my backup issues? if so is there a way to prevent this, or do we simply need to plan the backups at different times that don't overlap?
Thanks
We had another call with Quest today and figured out a solution to the problem.
It would seem that when configuring the backup through Quest Rapid Recovery, you have the option to do Machine level backups or Volume level backup. When it's configured to do volume level backups you can choose for it to either do a block level backup which isn't SQL Server aware, or for it to do a backup that is SQL Server aware, which ends up using the volume shadow copy service and these backups show up as Full (Copy Only) backups in the SQL backup history...even though you can't restore them from SQL Server.
Rapid Recovery can only do backups on a schedule, plus has the option to Truncate Logs after the backup complete to avoid filling the log files, but can't do transaction log backups, so you loose the ability to do a more granular recovery down to the second like with the native SQL Timeline Recovery...Which is why we chose to use native SQL Server Backups.
So to fix the issue, you need to either do a machine level backup which has not SQL Server Awareness/integration. Or you can do a volume level backup, but disable the SQL Server Writer extension, and the truncate logs options to remove the integration.
We've run a bunch of tests, and from the point/time that this change was done, we only see SQL Server backups and no longer the Rapid Recovery backups in the SQL Server Backup history.
So now i am in talks with my server/backup admin see if we can do a machine level backup once a day, so that we can do a machine level restore in case of disaster, and also add a volume level backup of my Backup drive, so that he captures my backups more frequently during the day. I think once this is complete, we'll have the best of both backup solutions.
Ability to do machine level restores (Rapid Recovery)
Retention of SQL Server Backups (Rapid Recovery)
Flexible point in time recovery (SQL Server)
Just wanted to post a update to this issue
We scheduled a call with Quest yesterday, and they assured me that their backup is only taking volume snapshots and will have no impact on my SQL backups. They said that the reason that i was seeing these errors is likely do to Rapid Recovery(I guess AppAssure was renamed to Rapid Recovery) and my SQL backup jobs both trying to use the volume shadow copy service at the same time and so we simply needed to stagger the backup jobs. I end up finding out that this wasn't completely true because the Rapid Recovery backups were configured to truncate my SQL Logs. I also told the guy from rapid recovery that when i queried the msdb backupset table that i was seeing backup jobs listed that lined up with the times of the rapid recovery backup. Still he assured me that it would have zero impact on my backups.
I was still concerned that the Rapid Recovery backups might be impacting the chain of my backup files, so in our test environment i right clicked on one of our databases and clicked tasks > restore >database just to see the recovery history. I see a database backup listed as type Full (Copy Only) which coincides with the rapid recovery backup, then a number of my transaction log backups.
It would seem to me that Rapid Recovery is definitely impacting my SQL Backups.
One other thing to note that i just tried in out test environment. I did a few tests backups using Full's , Transaction Log, Differentials and Full (Copy Only) just to see how things showed up in the restore window in SQL Server Management Studio.
So i realized that in the default restore screen, it tries to recover to the nearest point in time using the least combination of various backup files. To go past the last full backup, I have to use the Timeline option.
I could see the Full backup as the first item, and then the transaction logs backups.
Once i do the Differential backup, i see the Full plus the differential, but no more transaction log backups.... which makes sense since it's trying to get the the closest time possible for the recovery.
Next if i do another Transaction Log backup, I see the Full, Differential and the Transaction Log back
One thing that surprised me however is if i do a Full (Copy Only) followed by a transaction log backup, that i see these two item in the list of files for the recovery, yet if i do a differential after a Full (Copy Only) that it show me the last Full (non copy only), plus the differential. I expected that the backups would always be based off of the last full, both for transaction log and differential backups. I thought that the Copy Only backups would be ignored in the backup chain.
Next I decided to use the timeline restore feature and select a point in time during my tests where the Rapid Recovery backup wasn't part of the listed backups, and do a verify backup. As expected it was successful. After this i tried a restore to another point in time where the Rapid Recovery Full (Copy Only) backup was listed and the verify failed on the Full (Copy Only) backup file from rapid recovery, since it doesn't exist on the sql server.
Any recommendations on how to fix this? The point of the Rapid Recovery backup is supposed to be to backup the machine, in case we ever loose the server and have to restore the entire server, plus for it to pick up my sql server backups to keep for retention, since i only keep 7 days worth of backup on the server itself.
You can check the error log file.
Your job may be the victim of deadlock transactions.
Backup file location may not have enough permission.
So, you should check all the possible error log files.

How to stagger backups

I have Windows scheduler calling a program that does a full database backup every day at 3:00am.
I would also like to do a transaction log backup every ten minutes.
What is the best way to sync these?
I understand that transaction logs are independent of full back-ups, but is it a problem if the two different tasks both do a backup at 3:00am? i.e. the database is asked to produce a full back-up and a transaction log back-up at exactly the same time.
Perhaps I should have one task and query SQL Server to see if the last full backup was more than 24 hours ago. If not, then do a transaction log backup.
As long as you're running SQL 2005 or higher, you can run log backups at the same time as a full backup without issue. Glossing over a bit of detail, log backups are based on the last completed full backup at the time that the log backup started. The only time it really matters is when you'd need to do a recovery and even then, it's only ever "contentious" (i.e. "which full backup should I restore given that I want to restore to this point in time?") for log backups that are taken while a full backup is in progress.
If ever you need to do a point-in-time restore for such a time, you'd work backwards. That is, first find the log backup that contains said point in time. Then, to find the full backup that it's based on, look at the database backup lsn for that log backup in either msdb.dbo.backupset or by running restore headeronly on the log backup. From there, find the full backup that has that value as the checkpoint lsn. Now, you just need to restore that full backup (using the norecovery option) and every log backup based on it up to and including the log backup you identified in the first step (again, all using norecovery). Then run restore database [yourDB] with recovery to run crash recovery and you're back in business.

SQL Server LOG Data recovery

I was wondering how you can recover data from your logfile.
I'm using sql 2005 (full backup).
The problem is that a service cleared my data last night (which it shouldn't have).
and now I want to recover those rows that were deleted before.
can anyone tell me how I can do this?
As long as you have a backup of your database from before the delete and then all transaction log backups that have been made since the last database backup then you will be able to restore to a point in time.
The first thing to do is take a backup of the transaction log.
Then you restore your last database backup and all transaction log backups since then up to the point in time just before the delete.
See this MSDN Article on how to do it.
I would suggest that you leave your existing database in place as it is and restore the backups to a new database. Then you can write some scripts to transfer the required data back into your live database.
First of all, your database must be in the full recovery model and you must have a full chain of transaction log backups - a series of log records having an unbroken sequence of log sequence numbers (LSNs)
The log backup chain is started when a full database backup is made or the recovery model is switched from SIMPLE to FULL and a full backup is made. After that, transaction log backups are created on regular basis. The log backup chain can be broken only in two ways:
Overwriting the backup set
Switching from FULL to SIMPLE or BULK LOGGED recovery models
Breaking the log backup chain can lead to missing transaction information
You can restore to a point in time using:
SQL Server Management Studio, as shown in the link Robin provided
Using T-SQL and the STOPAT option
Syntax
RESTORE LOG database_name
FROM <backup_device>
WITH STOPAT = time, RECOVERY…
Use a third party tool, such as ApexSQL Log which can not only restore to a specific point in time, but selectively roll back only the transdactions you selected
You can find the steps for all listed options here: Restore a database to a point in time
Disclaimer: I work for ApexSQL as a Support engineer
Your data can be recovered only in case:
1) database uses full recovery model;
2) you have full backup that you make before accidental deleting;
3) you have have NOT recover or backup again this database yet.
If this is correct, you should:
1) make transaction log backup;
2) restore database from full backup WITH NORECOVERY option;
3) restore transaction log using STOPAT option.
To restore transaction log files to a point-in-time your database must run under full recovery model. So firstly you have to restore the latest full database backup:
RESTORE DATABASE *database* FROM DISK = 'D:/Full.bak' WITH NORECOVERY, REPLACE
The next step is to restore the last differential database backup:
RESTORE DATABASE *database* FROM DISK = 'D:/Diff.bak' WITH NORECOVERY
And then restore all transaction log backups that have made since last differential backup in correct sequence
RESTORE LOG *database* FROM DISK = 'D:/log1.bak' WITH NORECOVERY
RESTORE LOG *database* FROM DISK = 'D:/log2.bak' WITH NORECOVERY
RESTORE LOG *database* FROM DISK = 'D:/log3.bak' WITH NORECOVER
The last one transaction log backup that must be restored is the transaction log backup that have been made after the failure occurred with stopat option. After stopat option, you should set up the time to which you want to restore your database.
RESTORE LOG *database* FROM DISK = 'D:/log4.bak' WITH STOPAT = '2015-11-26 16:22:40.000', RECOVERY

sql server 2008 restore with transaction log?

I am developer so need your advice on how to plan for it
I am having sql server 2008.
I am going to through what they have in maintance wizard
And found that they have full, differential and transaction log.
So if i take one full back once a week then differential backup every day. Not sure how transaction log fit into this.
I assume sql server is saving transaction log some where so in case of failure I can restore from last differential backup coupled with full backup.
What i need to use transaction log on top of it? Where is transaction log saved?
I need this for application data loss issue, if in case some action made it delete some data so i need ability to go back point in time.
You must backup your log too, explicitly. Schedule a job to backup the log at short intervals (15 minutes to an hour usually). When you do a recovery, you apply the full backup, then the newest differential and then all the log backup after the differential.
Only with log backup can you restore the database at a specific moment, using the 'WITH STOP AT'. See: How to: Restore to a Point in Time.
Also to recover from a crash, you backup the log tail then apply the recovery (full->differential->logs->tail) and hopefully occur no data loss at all.
A Zero loss strategy require the involvement of replication in some form. Then you'll also need a failover server to account for replication time before the "slave" server is fully up to date.
Even with transaction log backups your still at risk for losing X data, where X is your transaction log backup interval.
Maybe edit your question?

Resources