How to decrease sql server backup time I have a 200 GB SQL Server database (including a file stream) which is taking more than 20 hours to backup on a nightly basis. What is the most cost effective way of decreasing this time?
I could add more hardware. Are backups IO, CPU or memory bound?
Or do I need to isolate the database which is currently on shared infrastructure?
Or can I make some coding changes to remove file stream data into blobs?
Referencing the post Backup to multiple files for faster and smaller SQL Server files

Problem

Have you ever wished you could get your backups to run faster? Well there may be a way, by writing to multiple files. Creating SQL Server backups is pretty simple to do; you can use the SQL Server management tools or you can use T-SQL commands to issue the backup. But sometimes with large databases it takes a long time to run and it is difficult to copy this very large file across the network or even to your backup tapes.

Solution

Write your database backup to multiple files. In addition to writing your database backup to one file you have the ability to write to multiple files at the same time and therefore split up the workload. The advantage to doing this is that the backup process can run using multiple threads and therefore finish faster as well as having much smaller files that can be moved across the network or copied to a CD or DVD. Another advantage to writing to multiple files is if you have multiple disk arrays you can write your backup files to different arrays and therefore get better I/O throughput. One thing to note is that to maintain the I/O throughput you should keep the writing of your backup files and the reading of the database file on different disk arrays.

Backup to multiple files using T-SQL

BACKUP DATABASE [Northwind] TO 
DISK = 'C:\Northwind_file1.bak', 
DISK = 'D:\Northwind_file2.bak', 
DISK = 'E:\Northwind_file3.bak', 
DISK = 'F:\Northwind_file4.bak' 
WITH INIT , NOUNLOAD , NAME = 'Northwind backup', NOSKIP , STATS = 10, NOFORMAT




A 200gb database is not really that large and (in my opinion) shouldn't take anywhere near 20 hours.  I would also do some testing on your backup target latency without even dealing with SQL Server.