Windows 2008 Client Backup Slow on System State Objects

[jgraul]

We are seeing some very large gaps between the start of the SYSTEMSTATE incremental and when the objects are actually assigned for the systemstate backup, sometimes over 2 hours. The ones with the big gaps are all Windows 2008 systems, but not all of our Windows 2008 systems have this large gap. Our server is 6.3.1 and the clients are either 6.2.x or 6.3.0. Here's an example of the dsmsched.log showing the gap:

09/13/2012 22:00:36 Incremental backup of volume 'SYSTEMSTATE'
09/13/2012 22:00:54 Backing up object 'ASR Writer' component 'ASR' using shadow copy.
09/13/2012 22:00:54 Backing up object 'ASR Writer' component 'This is the path to the boot BCD store and the boot managers.
All the files in this directory need to be backed up.' using shadow copy.
09/13/2012 22:00:54 Backing up object 'ASR Writer' component 'Select this volume (\??\Volume{3403d324-2266-11e1-94b1-806e6f6e6963}) if it is a critical volume.
Critical volumes are those which ASR must restore.' using shadow copy.
09/13/2012 22:00:55 Backing up object 'ASR Writer' component 'Select this volume (C if it is a critical volume.
Critical volumes are those which ASR must restore.' using shadow copy.
09/13/2012 22:00:55 Backing up object 'ASR Writer' component 'Select to include disk #0 (of signature 0x14b28a84) for ASR restore.' using shadow copy.
09/13/2012 22:00:55 Backing up object 'ASR Writer' component 'Select to include disk #1 (of signature 0x42121a4) for ASR restore.' using shadow copy.
09/13/2012 22:00:55 Backing up object 'COM+ REGDB Writer' component 'COM+ REGDB' using shadow copy.
09/13/2012 22:00:56 Backing up object 'Performance Counters Writer' component 'Performance Counters' using shadow copy.
09/13/2012 22:00:56 Backing up object 'Registry Writer' component 'Registry' using shadow copy.
09/13/2012 22:00:56 Backing up object 'System Writer' component 'System Files' using shadow copy.
09/13/2012 22:00:58 Backing up object 'Task Scheduler Writer' component 'Tasks Store' using shadow copy.
09/13/2012 22:00:58 Backing up object 'VSS Metadata Store Writer' component 'VSS Express Writer Metadata Store' using shadow copy.
09/13/2012 22:00:59 Backing up object 'WMI Writer' component 'Windows Managment Instrumentation' using shadow copy.
09/13/2012 23:57:06 ANS4085I Assigned '78654' objects from previous systemstate backup to the new systemstate backup.
09/13/2012 23:57:39 Backup of object 'SystemState' component 'System State' finished successfully.
09/13/2012 23:57:40 Successful incremental backup of 'SRCS202\SystemState\NULL\System State\SystemState'

Any ideas why this might be so slow on some systems?

 

[meurnt]

Could you please check CPU and Physical memory usage when the backup is running on this node and also update me the client version level..

Thanks
Krish
http://www.tsmguide.co.cc

 

[GregE]

jgraul, same problem here. Did you find any info?

 

[GregE]

Found another thread that pointed to this.
http://www-01.ibm.com/support/docview.wss?uid=swg21470662

NOT good at all.

 

[GregE]

This is getting messy fast. Backups severing all over the place as they run into their reboot schedules.

 

[jgraul]

Although I'm not happy to see others having the same issue, I'm happy we're not the only ones!

We are still seeing the problem on a lot of W2K8 systems.

I've asked our server guy to gather some performance counters during the backups on a few servers to see if there is a bottleneck.

 

[jgraul]

We just reviewed a couple of servers that have the long delay with VSS. The server is mostly idle during the time between the last VSS backup call and when VSS responds with the number of objects to backup.

 

[GregE]

Watch it closely. I did not notice these issues until 3 weeks ago. Before that all backups were completing inside my window. Now MANY are going far outside the window. The change is significant.

 

[Trident]

On the server running slow, check size of c:\adsm.sys

It should normally be pretty small, both in terms of bytes and number of files.

If it is large (>1Gb), then a client upgrade is in place. Some versions does not clean up the adsm.sys folder properly.