Backup taking more time than usual

  • It does vary quite a bit. As an example, a Litespeed backup of a 350 GB database over the network to a NAS file share went from 4-5 hours to 2 hours using 15 output files.

    Generally, there does not seem to be much gain when increasing the number of output files to more than 5.

    I have implemented this a number of times in situations where the speed of the backup is very important, and went to the trouble of writing a stored procedure to do it.

    I first discovered this when I was forced to backup to a compressed directory due to space limitations and had problems with the backup erroring out when the backup file was large. I tried backing up to multiple files and it fixed that problem, but I found that the backups also ran much faster.

  • Wow, so 50% savings is possible. I'll keep that in mind when are backups become too slow.

    Thanks.

  • Usual warnings: Your mileage may vary. Test it yourself. Don't blame me if you hurt yourself.

    I will say that I have yet to see a case where they were slower. I didn't mention that restores seem to run faster also.

    Also, it gets to be a bit more trouble to handle purging old backup files; I think most of the code in my backup stored procedure is actually devoted to that.

    Automatic restores of multifile backups to another server are a good bit more difficult to setup, since you have to get all the backup files into the restore command.

    I recently implemented an automatic restore of a 350 GB database using 2008 native backup compression and 5 backup files. The backup to the network share takes 20 to 60 minutes, depending on the load on the backup share, and the restore to another server takes 20 to 30 minutes.

  • I should preface all my messages with.

    I'm a moron, don't listen to me. Anything I say can destroy your servers and have you fired for doing what a clown on a message board told you not to do.

    However here's what I'd do :hehe:

  • Ninja's_RGR'us (9/8/2011)


    I should preface all my messages with.

    I'm a moron, don't listen to me. Anything I say can destroy your servers and have you fired for doing what a clown on a message bord told you not to do.

    However here's what I'd do :hehe:

    I just added a slide to a presentation I'm doing for Connections that says: Lies, lies, lies, lies. Just in case I'm not clear.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • :

    Grant Fritchey (9/8/2011)


    Ninja's_RGR'us (9/8/2011)


    I should preface all my messages with.

    I'm a moron, don't listen to me. Anything I say can destroy your servers and have you fired for doing what a clown on a message bord told you not to do.

    However here's what I'd do :hehe:

    I just added a slide to a presentation I'm doing for Connections that says: Lies, lies, lies, lies. Just in case I'm not clear.

    Ya that was funny (got the last half of the presentation yesterday).

    Any news on the stats used to generate the plan? :Whistling:

Viewing 6 posts - 16 through 20 (of 20 total)

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