• Please help support our sponsors by considering their products and services.
    Our sponsors enable us to serve you with this high-speed Internet connection and fast webservers you are currently using at ADSM.ORG.
    They support this free flow of information and knowledge exchange service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions
  • Community Tip: Please Give Thanks to Those Sharing Their Knowledge.

    If you receive helpful answer on this forum, please show thanks to the poster by clicking "LIKE" link for the answer that you found helpful.

  • Community Tip: Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING)

    Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.

Why does "snapshotroot" option make faster backups?

flex

ADSM.ORG Member
#1
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

ADSM.ORG Moderator
#2
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

ADSM.ORG Senior Member
#3
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.
 

Advertise at ADSM.ORG

If you are reading this, so are your potential customer. Advertise at ADSM.ORG right now.

UpCloud high performance VPS at $5/month

Get started with $25 in credits on Cloud Servers. You must use link below to receive the credit. Use the promo to get upto 5 month of FREE Linux VPS.

The Spectrum Protect TLA (Three-Letter Acronym): ISP or something else?

  • Every product needs a TLA, Let's call it ISP (IBM Spectrum Protect).

    Votes: 16 18.8%
  • Keep using TSM for Spectrum Protect.

    Votes: 52 61.2%
  • Let's be formal and just say Spectrum Protect

    Votes: 10 11.8%
  • Other (please comement)

    Votes: 7 8.2%

Forum statistics

Threads
31,449
Messages
133,979
Members
21,549
Latest member
idhelmyy
Top