VSS SYSTEM FILESET on Windows 2008 are running very slow.

I guess you are talking about NetWorker .. I hope someone may help you ... Unfortunatly I'm neither a backup expert nor a NetWorker expert .. But welcome to our forums!

Hmm Rob .. probably you know the ONLY NW instructor in Italy .. not necessarily the best

If it's the only one, isn't it automatically the best ?

I'm going home now, have a good evening !

I know EMC's best Networker teacher in Italy Should I ask him to help you ?

Hello anujajju and also welcome to the forums, though you've already been greeted by the best!

I have moved your question from the Coffee Break forum into the Networker forum,. It is more likely to receive a technical answer here.
Regards
Julie
Forums Admin

Naujajju,

Please tell us the whole story (without CAPS-lock );
* Networker Versions
* O.S. (windows 2008)
* etc

Message was edited by:
Antoine Schokker

It might be big if you use DFS-R if I remember correctly. As to speed, it might be either network issue or the client can't simply push it more than that (which would be strange).

It could be that you have turned the Windows System File Protection on which is backed up as part of the System Fileset - this caches important OS files to prevent them being accidentally deleted; that may account for the increased size. However 22 hours for 9GB is very slow unless you have used yogurt pots and string...
Can you confirm regular file system backups went through okay in a reasonable amount of time (this should eliminate network issues as the source of your problem)
Do you have other backups running simultaneously, what are you backing up to? If tape drives fail to get enough data sent to them they can "shoe shine", having to move the tape back and forth as data fails to stream.
Has the speed of backup been consistent or did it backup a large portion in a reasonable time then slow down?
Do you see any other issues on the Windows client?

Hello Anuj, the answer is that there is a design issue in NetWorker which is currently being investigated. Essentially, you may find that a NetWorker client which is using VSS (ie. W2K3 with a VSS license, or ANY W2K8 client) and is a DFS server may experience speed issues backing almost any data up.

What happens is that the DFS Replication Writer is consulted during a filesystem or system state backup - and if the DFS namespace contains a long list of files, you are forced to wait while save.exe enumerates the entire DFS structure.

Microsoft's specification states that DFS files must be backed up via this writer to avoid the risk of recovering a DFS file overtop of a newer version - which is effectively an authoritative recovery and will therefore replicate over newer versions.

Our own implementation also calls for DFS files to be skipped which inhabit a local filesystem so that we are not backing up the same data twice (via VSS SYSTEM BOOT and via filesystem).

The net result is huge DFS installations suffer on most types of backups due to the need to recurse. See Powerlink article esg107678 for more details. If you wish to be notified when this feature is fixed, please call and ask to be added to the Affected Customer list for LGTsc30840, which is tracking the design change to improve performance.

HTH, James.

I've had problems with VSS savesets myself but haven't encountered speed problems. I've had over 10GB VSS backups each day which is kinda lot in my point of view.

I went and got the LGTsc20343 fix which seems to make the ~10GB save sets around 66% smaller. Testing the recovering at the moment to see if it affects it in any way.

You can use only the libasm.dll for 7.4.x, for windows 2008, by default it uses, libvss2008.dll

So only libasm.dll is needed in win 2008 system.