Return to Revisions

Lets first get the concept of reader / writer threads out of the way

During a backup, SQL Server creates one reader thread for each volume that the database files reside on. The reader thread simply reads the contents of the files. Each time that it reads a portion of the file, it stores them in a buffer. There are multiple buffers in use, so the reader thread will keep on reading as long as there are free buffers to write to. SQL Server also creates one writer thread for each backup device to write the contents of the buffers out to disk or tape. The writer thread writes the data from the buffer to the disk or tape. Once the data has been written, the buffer can be reused by the reader thread.

Source

Answer

So yes, while the reader threads are reading the pages and the writer threads are writing the pages to the separate disk, the time to process the pages will be impacted by both.

But, this does not mean that the79.088 MB/sec will be divisible by 2.

It means that the read operation could handle 79.088MB/Sec and the write operation could also handle 79.088MB/Sec. The bottleneck is on one of these two operations.

Another way to validate this is by calculating the MB/sec * backup duration. This will be close to your database size.

Testing how fast you can read

If you want to know the amount of data & how fast it can be read from disk, you can take a backup to 'NUL'

BACKUP DATABASE DBName TO DISK = 'NUL';

In my case I ended up with 122.406 MB/sec

Testing how fast you can write

To know how fast you can write, you could use Crystaldiskmark.

Use Seq Q32T1 to mimic backup operations.

Source

This is what pops up on my slow drives

Putting them together

If I then run my backup command from to that disk I just checked with CrystalDiskMark:

BACKUP DATABASE DBName TO DISK = 'E:\Folder\DbName.BAK';


Processed 703088 pages for database 'DbName', file 'Database' on file 1.
Processed 2 pages for database 'DbName', file 'Database' on file 1.
BACKUP DATABASE successfully processed 703090 pages in 50.198 seconds (109.424 MB/sec).

As a result,

Your backup speed is determined by the bottleneck on reading or writing.

Source