Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Disaster recovery Expand / Collapse
Author
Message
Posted Wednesday, May 15, 2013 3:46 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: 2 days ago @ 9:08 AM
Points: 100, Visits: 328
Hi,

Can anyone please help me...I am new in SQL Server.

I have scheduled the database backup---
full backup-- everyday morning
differntial backup--every 2 hour
log backup-- every 1 hour.

my doubt is, log backup is running every 1 hour and disaster comes after that for example log backup is running at 12 PM after that backup done at 1 PM , suppose the disaster comes at 1:05 PM , so how can we recover the database at point in time
Post #1452998
Posted Wednesday, May 15, 2013 4:01 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Thursday, September 4, 2014 7:40 AM
Points: 3,546, Visits: 2,652
arooj,

First of all, the most generalized setup for any OLTP enviroment I've seen is:
full backup-- Weekend
differntial backup--daily once [usually end of day]
log backup-- ranging from 30 mins to 3 hours depending on the nature of database

For recovery at particular point, you can search for "point in time recovery" in google to check how the database can be recovered with this setup.

Hope this helps.
Post #1453002
Posted Wednesday, May 15, 2013 4:25 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 3:39 PM
Points: 42,953, Visits: 36,110
Depending on the type of disaster, you may be able to take a tail-log backup (google or see BoL).

If you can, then your restore would be last full backup, last diff backup, log backups since the diff backup and then the tail log backup for a restore to point of failure.
If you can't, then your restore would be last full backup, last diff backup, log backups since the diff backup ending with the 1pm log backup for 5 minutes of data loss.



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1453003
Posted Wednesday, May 15, 2013 7:04 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: 2 days ago @ 9:08 AM
Points: 100, Visits: 328
Thank you very much for replying me...............
Post #1453072
Posted Wednesday, May 15, 2013 7:32 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, August 29, 2014 11:33 AM
Points: 68, Visits: 409
By having the log backups every hour you are saying you can live with the loss of up to an hour of data. If this is not acceptable to you, or your company, you can take log backups every half hour or every 15 minutes. In any case, there is still potential for data loss. Its about figuring out what your company is comfortable with and communicate that, so there are no surprises.
Post #1453091
Posted Thursday, May 16, 2013 6:26 AM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: 2 days ago @ 6:31 AM
Points: 617, Visits: 866
Using the weekly scenario that was mentioned, it will help your sanity if...

1) Schedule the Weekly Full backup (i.e. Sun) and the Daily Differential (M-F or M-Sa) at the same time of day

2) Schedule the log backups at a slightly odd start time (i.e. 12:01:35) so they can not run (and will not be running) when either the Full or the Differential is running.

3) Additionally, or as an alternative, to have the log backup job disable the log backup before the Full or Differential begins, and re-enable it when the Full or Differential is complete.

4) Experience and familiarity with the particular server, databases and application will help you to know how long the backups might run. Usually the Differentials are much quicker than the Full backup, but if a database has heavy user traffic it might take longer and also might consume more drive space toward the end of the week.

FWIW, nearly all of my databases (over 300 servers) are set up with Log backups every 15 minutes, but will not run during the Full or Differential backups. If a server has multiple user databases, I try to stagger the run times.


Regards, Mike
Post #1453472
Posted Thursday, May 16, 2013 6:47 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: 2 days ago @ 9:27 AM
Points: 5,364, Visits: 9,867
There's no reason a log backup can't run at the same time as a full or differential. Indeed, if your full takes a long time to run, and you suspend log backups in the meantime, you're compromising your ability to do a point-in-time recovery.

John
Post #1453483
Posted Thursday, May 16, 2013 6:54 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 3:39 PM
Points: 42,953, Visits: 36,110
Mike Hinds (5/16/2013)
2) Schedule the log backups at a slightly odd start time (i.e. 12:01:35) so they can not run (and will not be running) when either the Full or the Differential is running.

3) Additionally, or as an alternative, to have the log backup job disable the log backup before the Full or Differential begins, and re-enable it when the Full or Differential is complete.


The former won't achieve its intended result when you have a full backup that takes more than an hour and to be honest, there's no good reason to stagger backups like that. You can't run a full and a diff together, but log backups will run concurrently with full backups (since SQL 2005), which is great when you have a small data loss allowance and a long running full backup.

I've had a scenario where the data loss allowance was 15 minutes and the full backup took 7 hours every week. Suspend the log backups while the full's running and I've got a scenario where I can have a disaster occur and lose 20x the data that's allowed for.



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1453491
Posted Thursday, May 16, 2013 7:07 AM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: 2 days ago @ 6:31 AM
Points: 617, Visits: 866
John, Gail -

Put simply, "I hadn't thought of that". Thanks for the input.

Without intending to hijack the thread, there are several other considerations involved:

1) I'm at a regional bank, and the Full and Differential take place in non-bankers-hours, no users online at that time

2) The weekly full backup is part of a multi-step maintenance job that also performs DBCC CHECKDB, index rebuilds, etc. It first performs a "Final" Log Backup, then changes to SIMPLE, performs the maintenance, then changes back to FULL immediately before the Full backup step.

3) I always perform the first log backup immediately following the completion of either the Full or Differential.

But with what you've shown me I think I can immediately cease disabling the log backup, at least during the differentials.


Regards, Mike
Post #1453501
Posted Thursday, May 16, 2013 7:18 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 3:39 PM
Points: 42,953, Visits: 36,110
Mike Hinds (5/16/2013)
2) The weekly full backup is part of a multi-step maintenance job that also performs DBCC CHECKDB, index rebuilds, etc. It first performs a "Final" Log Backup, then changes to SIMPLE, performs the maintenance, then changes back to FULL immediately before the Full backup step.


To be blunt, that's not a good idea.

Do you test restores? If not, let's say that the full backup after the maintenance is damaged and you don't notice it. 2 days later the database drive fails and you need to restore. Easy enough, full backup, latest diff, all logs since then, except the full backup is damaged and won't restore.

So, go back to the previous full backup, restore the diff, restore all logs. Great, but the last log that will restore is the one right before the switch to simple recovery model. You've just lost 2 days of data.

If you want minimal logging for the index rebuilds, consider bulk-logged recovery rather than simple. Yes, the log backups over that period will be huge, but at least you'll have an intact log chain and multiple options for restoring if there's some disaster



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1453514
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse