Comments (7)

  1. Robert, Your comment “You get 1 backup thread per LUN or mountpoint, not per file.” Is that not dependant on the type of storage attached. Ie if SAN and the SAN consists of 10 underlying disks, If the presented MP has multiple Backup files placed onto it are you saying this still only gets 1 thread and will not perform any better than 1 backup file.


    1. No, SQL Server is ignorant of the type of storage you have under the covers. When I say “backup thread” that’s a thread sending data to the IO subsystem and in now way signifues what happens in the IO subsystem one it gets the IO. The IO subsystem can absolutely affect the speed of the backup if the it can’t write the data as fast as it receives it.

      Good question, Warwick. Thanks for asking.

      1. Can you please clarify this again, because there are some typos in your post…

        So, no matter how many drives are “sitting” behind the MP, you are still going to work with one thread?

        What will happen if you start 2 database backups that reside on the same MP behind which there are 10 disks?

        1. The number of disks has no effect on the number of backup threads you get. SQL Server has no knowledge of the number of disks behind the storage. You get one backup thread per LUN or MP.

          Yes, of course, if you start 2 backups running at the same time, each one gets its own backup thread. They don’t share one.

  2. […] dedicated LUNs set up so they could speed up the backup by striping it across multiple drives (see Day 25 of 31 Days of Disaster Recovery: Improving Performance of Backups and Restores) so that the total backup time was within a reasonable window. Unfortunately, their database […]

Leave a Reply