Solved! Go to Solution.
Using OpenStorage client direct ..............
Seems you have Client Dedupe enabled?
As far as I know, Client side dedupe is not supported for DSF backups.
Will see if I can find documentation.....
Seems dedupe is supported for DFS. See this discussion: https://www-secure.symantec.com/connect/forums/best-practice-backup-dfsr-server10-tb-data-using-nbu-...
... the VSS writer for DFS is also in a waiting for completion state.
Not sure if this is causing the issue. A reboot may fix this. Please also check Microsoft Support site for VSS hotfixes.
You may want to change dedupe options for this client if 'Always use client-side deduplication' is selected to 'Prefer to use client-side deduplication'.
Hopefully someone else will suggest something more helpful.....
Your job is using Accelerator as well as client side de-dupe and your error actually relates to getting a handle on the disk storage itself
There is a gap from 20:01 when it starts writing up to 01:18 when it fails
It could be that you are hitting a timeout or a keep_alive timeout - it may also be that the fragement size on the de-dupe storage unit is too large and causing these timeouts
It looks like it only passed 1GB of data in 5 hours - so i would say it is hitting a timeout somewhere here - or the de-dupe isunder too much load causing it to run very slowly
What sort of de-dupe is it? PureDisk, MSDP, Appliance? -- It may need to be tuned or cleaned up
Ok - usual stuff with keeping on top of queue processing - but if you are suing accelerator in an appliance then you should also tune it so that it doesnt run out of content router threads (which may be part of your issue)
So edit (vi) the /disk/etc/puredisk/contentrouter.cfg file and change the value for WorkerThreads from 64 to 128
It needs at least a NetBackup service re-start to take effect but i like to clean up the queues and then give the appliance a reboot to make sure that this setting gets put into action
This should help with the issue you are experiencing but also check under usr/openv/netbackup/db/ for any DPS_PROXY*** files
You really only want to have one in there which is DPS_PROXYDEFAULTRECVTMO and it should have a vlaue of 800 in it
You can also add this file to the same location on your master server - just keeps the disk checks more efficient in a busy ststem and stops disk showing as downduring very busy periods
These two really should help out - but do check that the client is OK and not struggling with doing client side dce-dupe and accelerator or if it has Anti Virus or anything holding it back