BE 2010 SQL Backup taking 20+hrs to run...

[Wayne_Maranduik]

I have a BE 2010 backup job on a SQL 2005 DB that takes over 20 hours to complete...is there any way to make it complete faster?

It seems that the majority of the backup job is spent in a "pre-processing" stage.

The other issue with the job taking 20+ hours to complete, is that it utilitzes one of the 2 available tape drives in my HP Tape Libarary...that means that ONLY 1 tape drive is available during the 20+ hours it takes to complete this job, which limits my other backup jobs that are scheduled.

This is a real issue and I am open to suggestions to try to:

1) Cut down on the time it takes to complete the backup job

2) Free up the tape drive while the "pre-processing" is taking place

Thanks

Wayne

[CraigV]

Hi,

If you're using AOFO turn this off as your first point of troubleshooting. It does cause issues.

What sort of speeds are you getting too, and what device are you backing up too (LTOx)?

You can read up on the TN below for more information if your backup is running slowly...it relates to slow throughput etc.

http://www.symantec.com/docs/TECH8326   

[VJware]

Have you looked at:

http://www.symantec.com/docs/TECH78109

http://www/symantec.com/docs/TECH23843

[Wayne_Maranduik]

Hi,

AOFO is not enabled on this job.

The Tape Library is for LTO Ultrium 2 200/400GB tapes.

Summary is as follows:

Byte count          : 821,500,292,133 bytes
Job rate            : 3,259.65 MB/Min (Byte count of all backup sets divided by Elapsed time for all backup sets)

Files               : 37,468
Directories         : 5,360
Skipped files       : 3
Corrupt files       : 0
Files in use        : 0

The job is setup for the SQL databases, The local C: Drive, System State and Shadow Copy Components.

SQL is setup to backup Full DB's, Physical Check ONLY on the Consistency Check before backup.

Thanks

Wayne

[Wayne_Maranduik]

More information...

Job Summary:

Job Started - Sunday Dec. 04 11:00:02 PM

Job Ended - Monday Dec. 05 7:08:51 PM

Elapsed Time: 20:08:49

Set Detail - C:

Start Time - Sunday Dec. 04 11:04:09 PM

End Time - Sunday Dec. 04 11:21:05 PM

(NOTICE THE DELAY...16 HOURS!!)

(I beleive this is all "pre-processing" on the SQL portion of the Backup)

Set Detail Microsoft SQL Server

Byte Count - 809,093,740,019 bytes

Rate - 3,498.00 MB/MIN

Start Time  - Monday Dec. 05 3:21:41 PM

End Time  - Monday Dec. 05 7:04:37 PM

Set Detail Shaow?Copy?Components

Start Time - Monday Dec. 05 7:04:47 PM

End Time - Monday Dec. 05 7:05:03 PM

Set Detail System?State

Start Time - Monday Dec. 05 7:05:11 PM

End Time - Monday Dec. 05 7:07:43 PM

[CraigV]

...are you perhaps doing some sort of consistency check on SQL before running the backup?

[WoCom]

Had it too, it is definitely the consistency check that is happening when "pre-processing".

Set the Consistency check before and after backup to None and backup will be much faster.

Maybe a good idea to check why the consistency check in SQL takes so long.  I think you can execute this on SQL-server with command "dbcc checkdb with physical_only"

Kind regards,

Wouter

[pkh]

Turning off the consistency check before the backup is not a good idea.  You would not know whether your database is good or bad.  If a database is inconsistent, you might as well forget about backing it up.