DB Backups taking more time

  • Hi All,

    We have configured 2 jobs for db full backups and both jobs having the same number of databases

    [ i.e JOB 1 - Total size of all dbs - 1.07 TB and i.e JOB 2 - Total size of all dbs - 1.11 TB].

    But JOB 1 is taking more than 30 hours for full backup of all databases and

    JOB 2 is taking more than 9 hours for full backup of all databases.

    Can some one please advice on this.

    Thanks and Regards,

    Ravi.

  • Dear Ravi,

    From your post, it is not clear whether these two jobs are running on the same servers or on different servers; secondly; the backup drives used for each server, are they attached locally to the servers from where the backups are being taken or are on network share path?

    What about the backup drives media? Are both backup devices having same type of media and performance?

  • ravisamigo (7/16/2012)


    Hi All,

    We have configured 2 jobs for db full backups and both jobs having the same number of databases

    [ i.e JOB 1 - Total size of all dbs - 1.07 TB and i.e JOB 2 - Total size of all dbs - 1.11 TB].

    But JOB 1 is taking more than 30 hours for full backup of all databases and

    JOB 2 is taking more than 9 hours for full backup of all databases.

    Can some one please advice on this.

    Thanks and Regards,

    Ravi.

    Hi Ravi,

    Please provide more details.

    Check your question from our end and provide necessary input like mentioned in above comment.

    --rhythmk
    ------------------------------------------------------------------
    To post your question use below link

    https://www.sqlservercentral.com/articles/forum-etiquette-how-to-post-datacode-on-a-forum-to-get-the-best-help
    🙂

  • Thanks for your prompt reply.

    Both jobs are running in the same db server.

    JOB 1 - > DB Backups are locating in L:\ --> it's connected from different storage server [ DELL NX ]

    JOB 2 - > DB Backups are locating in M: \--> it's connected from different storage server [Super Micros ]

    Thanks and Regards,

    Ravichandra.

  • Dear Ravi,

    thanks for sharing info;

    I am not that good at Storages.

    Anyways, as a quick check, if you have available required space; can you switch the backup of each job to other's backup drive just to check, whether the time difference is because of storage performance or because of some load on databases?

    Secondly, it is good to have storages attached locally to get good performance on backups;

    Lastly, if you can have multiple drives for each backup job; so backup can get be written almost at twice speed on two drives as compare to writing to a single drive.

    One more thing; in backup jobs; there is an option of MAXTRANSFERSIZE; ideally this should not be specified to get maximum backup performance; so just to be sure, check this setting as well in your backup script.

  • ravisamigo (7/17/2012)


    Thanks for your prompt reply.

    Both jobs are running in the same db server.

    JOB 1 - > DB Backups are locating in L:\ --> it's connected from different storage server [ DELL NX ]

    JOB 2 - > DB Backups are locating in M: \--> it's connected from different storage server [Super Micros ]

    Thanks and Regards,

    Ravichandra.

    So what is the timings of these jobs.

    Did you check if any other process is creating hindrance ?

    Also you mentioned different storage servers, so how about the past performance or these are newly created ?

    --rhythmk
    ------------------------------------------------------------------
    To post your question use below link

    https://www.sqlservercentral.com/articles/forum-etiquette-how-to-post-datacode-on-a-forum-to-get-the-best-help
    🙂

  • Is the slow backup job have enabled any of the reliablity settings like verify backup or perform checksum?

    i hope sql process wont delay the backup timings may be log backup slow down the process and check the storage connection speeds as well.

    Regards
    Durai Nagarajan

Viewing 7 posts - 1 through 6 (of 6 total)

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