Windows client side file list

[grosstech]

Hi:

    I have an issue with some Windows file servers with large hard drives > 1 TB.  Environment is 7.0.1 Master (Windows Server 2008) and Media Servers (Solaris 10 and Windows 2008) and various clients.  The problems are with 6.5 Windows 2003 file servers.  When the backups begin there is a long delay before data is streamed from the Windows client.  This delay can be up to 6 hours.  From tracker it appears that there is a file list which is being generated on the Windows client.  This occurs both during Full and incremental backups.  I have read conflicting posts about this sort of activity but I see it occurring.  There are some rather extensive Exclude lists and exceptions.  I am suspicious that this might be what is causing the file list generation.  Now that I am aware of the activity it is not that big of a deal but initially I was killing the jobs on the master which left quite a bit of debri on the client.  We would like to eliminate this activity if possible.  Thanks for any help.  --- Mark 

[RonCaplinger]

You are correct, NBU must "enumerate" the files to be backed up first and that is done by walking all the directory paths in the file system.  If you have a lot of files (over 1 million) on that drive, you will likely hit performance problems just as you describe.  This is true of ANY backup system that works like NetBackup.

One option for the Windows clients, provided the data change rate is low on that dirve, is to try enabling the Windows Change Journal and change your client properties to "Use Change Journal in incrementals".  It might reduce the time it takes to back up those files.  We tried it and didn't notice any difference.

Another option might be NetBackup's Flash Backup. It can do a volume-level backup as one big file, but it's not necessarily any faster, depending on how much there is to back up.

[Marianne · Accepted solution]

Check Task Manager on client to see if 'tracker.exe' is running.

How to disable client job tracker: http://www.symantec.com/docs/TECH31484

Scroll down to NetBackup 5.x , 6.x, 7.x section.

Also verify that client is using VSS for WOFB and not VSP. This is done in Host Properties -> Master -> Client Attributes. Add client name if not in this list and ensure VSS is selected.

Exclude lists are known for causing delays, but 6 hours seem excessive....
How 'extensive' IS your exclude list?

Any reason why you haven't upgraded NBU on these clients yet?

[Nicolai]

It may be the tracker that causes the delay - I had the same issues long time ago.

[grosstech]

Thank you for the responses.  On the large drives there are over 1 million files or close to it.  Why would I want to disable the client job tracker?  I had not used it before but the Windows admin was able to alleviate my concerns that something was running.  It was the tracker which exhibited the file enumeration.  I have read reports in this forum where NBU processes files as it encounters them which is what is desired but not exactly observed.  To disable the tracker is rather straightforward.  I did this last week when it was reporting erroneous information.  But this was because I did not think that jobs were progressing and killed a bunch of backup jobs on the master console.  They were left hanging around on the client.  I'm also familiar with the WOFB tab which IMHO Symantec left something to be desired in the Windows port.  How am I supposed to know what the current settings are?  On the Unix console there are radio buttons which illustrate the current settings.  The best that I can do in the Windows console is select the VSS click 'Apply' and watch the GUI bounce around and jump to another server even though I might not have been done configuring the one which I previously had selected.  Is there a way possibly in the backup details or a log which will indicate what WOFB method was used?  With respect to upgrades, I pointed out the dated versions of the software several months ago when I began this engagement.  It is a moderately large environment and change takes time.  This is in the works and the intent is to bring all the environment up to 7.5 within the next few months.  What will the later rev client software bring which will alleviate this situation?   I will escalate to upgrade these clients if there is something which will reduce or eliminate the file enumeration time.  The exclude lists are quite extensive.  Not lengthy per se but these machines were previously in an LTO-3 environment.  They were not able to complete their backups in a nightly cycle.  The NBU admin split these backups into 4 policies.  Fulls were partitioned and the large drives were essentially excluded from the policies with exceptions inserted to backup a particular segment tailored for each policy and schedule within the policy.  I have migrated these machines into an LTO-5 environment with greater networking capacities and have essentially eliminated the use of the exclude lists by having one policy per machine.  The naming convention of the policy has changed which to me means that it will not use the excludes embedded in the client  based upon policy name.  However, for CM purposes I have currently left the old excludes and their exceptions in place. artifacts.  I do intend to abandon and return to default values ie.  ALL_LOCAL_DRIVES and defaults in the excludes.  I can see where if the excludes and their exceptions were present that NBU might find it safer to create a backup file list rather than compare on the fly.  This is why I initially asked about the Exclude list and exceptions.  I will eliminate the old and return to defaults within the next few days unless I receive a definitive response that this is what is causing the file enumeration.  Again thanks for the responses.  

[grosstech]

Was able to get a Windows admin to disable the tracker and started a job.  I did confirm that the WOFB setting or at least attempted to set them from the master.  But, I had another large server which did a backup last night without the file listing delay and the tracker was not present.  Marrianne was right on target.  Thank you!  --- mig