Deduplication Queue Folder - How big is too big?

[TechyMr_B]

Hi All,

Just a general query regarding the "Queue" folder that sits within the deduplication storage drive on a media server.  

Have been talking to support regarding backup job issues with one of our media servers, and was told that the Queue folder had a lot of records held in it.  I wanted to check what the recomended/average size this folder should get to before it causes issues?  One of our media servers is showing that it is currenty at 37.6 GB, the faulty media server reported to Veritas has 291 GB of data.  

Queue processing is running but this value does not seem to drop?

Thanks in advance.

[VJware]

The "Queue" folder contains the transaction logs and they are batch-processed.

Number of these T-logs depends upon the data being backed up & deduped, so can't really say how big this folder can be and what the average size should be. (Its similar to asking how long a piece of string is & there isn't a right or a generic answer).

Check the storaged.log if queue processing is running fine or not. (Located at DeduplicationStoragePath\Log\Spoold folder)

[TechyMr_B]

Hi,  

Thanks for the response, I thought this may be the case but wanted to make sure.  Doing a lot of vmware backups on this particular media server.  I think the size also stems from the inability of the server to process the tlog files in the queue folder.  Running crcontrol shows that the oldest logs are from the start of this month.  

Veritas support have had a look into this but no results so far, also a reboot after support have looked at this have put the log processing back to the start again?? When i first looked at this it was about 3/4 way through processing the logs (according to the storaged.log file records count), after the reboot the counters appear to have reset and its going over old logs again???

Changes that were made were to the account used to run the Backup Exec service (was told to change this as the current service account "did not have the correct permissions in the BEDB database") and a registry change to the registry (CheckReclaimSpaceIntervalMinutes set to 1 instead of 60 for debug logging).

Many Thanks

EDIT: Checked BEDB permissions on working media servers and these look the same??

[VJware · Accepted solution]

Would recommend to suspend any jobs to the DeDupe folder & run a manual queue processing. Do not reboot as well, i am guessing reboot interrupted the queue processing causing the counters to reset.

Secondly, "CheckReclaimSpaceIntervalMinutes" registry key doesn't enable/disable debug logging. By default it is set to 240 (4 hours) i.e. the interval when DLM process runs.