Backup to three drives suddenly slow The situation: I have a 1.3 TB Database (SQL 2005) that I am currently backing up to 2 network shares on separate machines and on one local USB. (Don't ask why - long story involving a DBA that quit last night)
The backup started 12 hours ago and for the first 2 hrs it was showing an estimated total runtime of 8 hrs. For the last two hours it is showing an estimated remaining time of 90 minutes. It seems to be doing 1% per hor right now leaving another 8 hours to finish.

Perfmon is showing 6MB/s going out on the network and 6MB/s going in on an otherwise idle machine (share 1). Share 2 is not idle, so there is noise on the network but no significant trafic. USB drive is at 0 bytes a second for a while now.

Any Ideas of how to revive the two "forgotten" backup targets to get this backup finished before tonight?

P.S:ETA and percent completed coming from sys.dm_exec_requests

Backup command is:

BACKUP DATABASE [XXXXXXXXXX] TO  
DISK = N'D:\backup\XXXXXXXXXX_20121019_T3_A',  
DISK = N'\\server3\XXXXXXXXXXBak\XXXXXXXXXX_20121019_T3_B', 
DISK = N'\\server2\XXXXXXXXXXBak\XXXXXXXXXX_20121019_T3_C'
WITH NOFORMAT, NOINIT,  NAME = N'XXXXXXXXXX-Full Database Backup', 
SKIP, NOREWIND, NOUNLOAD,  STATS = 10, CHECKSUM


The drive that it is currently stil writing to is the one that we usually backup to. That usually takes 60 hours writing to a single file.
Do you have a fast spindle or spindle set that is not part of the DB itself to back up to?

Or even a tape drive local to SQL ?

If backup space is snug, a tool like redgate sql backup will compress a backup. A 1TB database might be 100-300mb compressed. The backup is much faster also, because the amount being written is so much smaller (our backups of 0.5TB went from an hour to 19 mins).

The key is to have sufficient space, either local on the box or local on a fast LAN, so you can do a straight, single shot backup. The target should be a spindle set that is not used for SQL data or logs, or any other high IO operation (as the backup itself is heavy IO).

Additionally: If possible, take the db to single user, or read only state before running the backup. In some cases this can improve performance (by eliminating concurrent IO to the db itself during the backup).