Disaster recovery

  • 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

  • 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.

  • 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, MVP, M.Sc (Comp Sci)
    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
  • Thank you very much for replying me...............

  • 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.

  • 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.

    Mike Hinds Lead Database Administrator1st Source BankMCP, MCTS

  • 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

  • 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, MVP, M.Sc (Comp Sci)
    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
  • 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.

    Mike Hinds Lead Database Administrator1st Source BankMCP, MCTS

  • 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, MVP, M.Sc (Comp Sci)
    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
  • Thanks again, Gail.

    I've enjoyed working with a new partner who has been helping me move from my old strategy to one based on the Ola Hollengren routines. He's confirmed that as it is implemented, the servers no longer use SIMPLE, but he leaves them in FULL. We knew that BULK_LOGGED was available.

    Mike Hinds Lead Database Administrator1st Source BankMCP, MCTS

  • by using Tail log backup, we are restoring up to last sec also

  • aaroo,

    Most suggestions are so far very helpful. 🙂

    I'd like to share a different perspective from Paul Randal that we should focus on restore strategy first then come up with backup strategy.

    Thanks.

Viewing 13 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic. Login to reply