Why does "snapshotroot" option make faster backups?

[flex]

We made some test backups on the same objects (test environment is a MS Windows machine):

1. WITH -snapshotroot=c: option:

Total number of objects inspected: 200,769
Total number of objects backed up: 3,265
Total number of objects updated: 0
Total number of objects rebound: 0
Total number of objects deleted: 0
Total number of objects expired: 4
Total number of objects failed: 3
Total number of subfile objects: 0
Total number of bytes inspected: 116.98 GB
Total number of bytes transferred: 16.07 GB
Data transfer time: 189.72 sec
Network data transfer rate: 88,841.37 KB/sec
Aggregate data transfer rate: 41,610.61 KB/sec
Objects compressed by: 0%
Total data reduction ratio: 86,26%
Subfile objects reduced by: 0%
Elapsed processing time: 00:06:45

2. WITHOUT -snapshotroot=c:

Total number of objects inspected: 200,777
Total number of objects backed up: 3,262
Total number of objects updated: 0
Total number of objects rebound: 0
Total number of objects deleted: 0
Total number of objects expired: 12
Total number of objects failed: 3
Total number of subfile objects: 0
Total number of bytes inspected: 117.49 GB
Total number of bytes transferred: 16.12 GB
Data transfer time: 203.63 sec
Network data transfer rate: 83,011.18 KB/sec
Aggregate data transfer rate: 31,752.29 KB/sec
Objects compressed by: 0%
Total data reduction ratio: 86,28%
Subfile objects reduced by: 0%
Elapsed processing time: 00:08:52

3. WITH -snapshotroot=c: option + SNAPSHOTPROVIDERFS VSS option

Total number of objects inspected: 200,368
Total number of objects backed up: 3,306
Total number of objects updated: 0
Total number of objects rebound: 0
Total number of objects deleted: 0
Total number of objects expired: 22
Total number of objects failed: 0
Total number of subfile objects: 0
Total number of bytes inspected: 117.29 GB
Total number of bytes transferred: 16.03 GB
Data transfer time: 211.86 sec
Network data transfer rate: 79,353.07 KB/sec
Aggregate data transfer rate: 34,115.23 KB/sec
Objects compressed by: 0%
Total data reduction ratio: 86,34%
Subfile objects reduced by: 0%
Elapsed processing time: 00:08:12

4. -snapshotroot=c: option + SNAPSHOTPROVIDERFS VSS option

Incremental backup of volume 'c:'
ANS2225W User has specified 'SNAPSHOTROOT' option. VSS snapshot backup is not valid in conjunction with this option.
"SNAPSHOTROOT option will take precedence and processing will continue without the use of a snapshot taken internally by TSM.
Unable to take a VSS snapshot for volume 'c:'.
Operation will be performed without using a snapshot.

Total number of objects inspected: 200,362
Total number of objects backed up: 3,494
Total number of objects updated: 0
Total number of objects rebound: 0
Total number of objects deleted: 0
Total number of objects expired: 122
Total number of objects failed: 0
Total number of subfile objects: 0
Total number of bytes inspected: 116.91 GB
Total number of bytes transferred: 16.15 GB
Data transfer time: 188.35 sec
Network data transfer rate: 89,910.64 KB/sec
Aggregate data transfer rate: 40,656.50 KB/sec
Objects compressed by: 0%
Total data reduction ratio: 86,19%
Subfile objects reduced by: 0%
Elapsed processing time: 00:06:56

Any explanation?

 

[marclant]

A one time test is not conclusive, there could be other variables in play here. Disk I/O, network I/O, how busy the Spectrum Protect Server is. For example, the Data transfer time and Network data transfer rate vary from backup to backup. That's not dependent on client options or the client machine. That's entirely dependent on the network, and how fast the Spectrum Protect server can write the data to media and do it's database updates.

I'd run each test 10 times or more, and take the average to see if it results are consistent. The results have to be reproducible in order to be meaningful.

 

[RecoveryOne]

Correct me if I'm wrong, but isn't snapshotroot really designed for network filesystems and providers that support snapshots? Performing a snapshotroot on a windows machine's C:\ drive will still call the MS VSS writers, hence the error of "VSS snapshot backup is not valid in conjunction with this option." in one of your tests.

As to marclant's statement, even if the system and TSM is 100% idle there's still a lot of magic behind the screen's that we don't see. Packets being dropped, fragmentation. Perhaps Windows decided it was a good time to engage one of its housekeeping tasks? There's a two minute and some odd seconds variation between your tests. That's negligible in my opinion. I start having concerns when my 200T lun goes from 12 hours to 20 hours . Then I'm pulling in people from network, san, and other areas to find out what occurred.

Now, on to your tests. If you really want to go down that road, I suggest you use a different node name for each round and exclude the tsm log files, and other tsm files as needed. If the files are open the client will spend time retrying to back them up. From the results you posted, it seemed that this was an incremental operation between runs. Since TSM and the client has to track what's changed between runs that does add some overhead. Especially if any sort of deduplication is occurring on the client or server. Now, that won't take into account all the noise of windows event viewer and other windows tasks.

I do understand your need for finding bottlenecks and improving performance. And in fact, that's still a large part of what I do. If I can reduce my backup window by 30 minutes everywhere, that gives me 30 extra minutes I can use for TSM server side housekeeping.