Dedupe verify very slow

[Bubbagump]

System:

8 core

24 GB RAM

4TB Dedupe disk

Win2k8R2 Std

BE 2010R3

Backups are doing just fine and run at a rate of roughly 2GB/min with 4 backups running concurrantly (greater than this using client side dedupe). However, verifies run at like 30-40MB a minute. For a 1TB SQL database backup, this is obviously unusable. I have read the threads here and people say it has to rehydrate and do it off peak and as a separate job and defrag and don't bother verifying (too paranoid not to) etc etc. I have done all of these and still the verify rate is miserable. I knwo it is not an I/O bottle neck as these run separately and there is practically no I/O while these run. Ideas?

[teiva-boy]

CPU speed, disk read speed for the dedupe database, and read speed of the disk where the dedupe volume reside all contribute to performance here.  

Can you do a perfmon during the verify process to see if there is any high cpu usage, queued disk reads during this process, or excessive disk swapping?

[Bubbagump]

There is hardly any of the above. ~22GB RAM free, <5% CPU used, nearly no disk I/O.

[Moltron1]

I too am getting really slow verify times, and also the byte count of the verify is really really off.  I'm talking hundreds of gigabytes higher than what the job is that its verifying.  I have a case open with Symantec on it.

My verify job rates are from the 200-700 MB/minute rate.  That on top of the inflated amount of data that its for some reason verifying, I've had to cancel many of the verifys since they run into the next backup cycle.

I think that the verify job rates got worse after I changed all my verifys from "linked to backups" to a scheduled time, but I forget exacty when I made that change.  They're driving me crazy, but I dont want to skip em.