Forum Discussion

stuart_clark1's avatar
11 years ago

SQL Full/Incremental Backups

Hi, hoping someone can help me out.

I am running BackupExec 2012 and am in the process of refining our SQL backups. I have progressed to the point where I have a full backup running once a week, a daily incremental (differential) running every night, and an hourly incremental log backup running. This, as i understand is the ideal scenario for backing up SQL data. I have approx 1.1TB across about 10 DB's.

The issue that i have, which i'm not sure if there is a way around, is the length of time my full backup takes. It's backing up to a SAN volume and takes around 20 hours to complete including verification. It averages around 3,600MB/min (60MB/sec) which isn't fantastic over 1Gb network but i'm happy with that speed for now. My concern is that whilst the full backup is running, the incremental logs backups are not. The idea of the log backups being i can restore to any given time within the space of an hour in the event of failure. As the full backup takes apporx 20 hours, and this will likely only increase over time, i effectively have a 24 hour period of potential data loss should something happen.

Is there anyway i can still have the hourly logs running whilst the full backup is running or is this just a limitation of software/DB design as it's in use? Can anyone suggest anything that may mitigate this risk? Thanks in advance!
  • No.  There is no way around this.  If this was possible, then this scenario may happen.  While you are doing a full backup, your log backup is done and the log is truncated.  After this the full backup fails, you are left with nothing to recover your database because your logs are gone.

    If you are backing up multiple SQL databases in one job, then you might want to split up the job so that the smaller jobs can finish faster.

    If you put your logs on a separate volume from the databases, this will minimise the chances of them being wiped out along with your database.  With your last full backup and your logs, you should be able to recover your databases, even without backing up your logs.

  • No.  There is no way around this.  If this was possible, then this scenario may happen.  While you are doing a full backup, your log backup is done and the log is truncated.  After this the full backup fails, you are left with nothing to recover your database because your logs are gone.

    If you are backing up multiple SQL databases in one job, then you might want to split up the job so that the smaller jobs can finish faster.

    If you put your logs on a separate volume from the databases, this will minimise the chances of them being wiped out along with your database.  With your last full backup and your logs, you should be able to recover your databases, even without backing up your logs.

  • Thanks for the prompt reply pkh, much appreciated. What i expected :)

    Can you explain your thoughts on how breaking it up would help? The overall runtime would still be the same wouldn't it? Or would it allow the scheduled log backup to complete once it was done, then the next part of the full to commence.
     

  • When you break up the job, each job is separate, the log backups can be done as soon as the full backup is done.  It is not dependent on the other full backups to complete.  In fact, you can run several full backups at once, although you might have contention problems doing so.

  • Okay, cool. I'll give it a go and see what results i get. Sounds like best way to go about it. If it ultimately increases log backup frequency and as such provides more protection, i can deal with it if it does take longer overall.

     

    Thanks mate.