AIX Job results folder full

Thanks made the change and managed to get a backup going again, having said that the job results folder on the AIX server still reports as full, I take it this will clear out after some time ?

I would remove the source-side disk cache (CV_CLDB) manually if you have access to the operating system and you have disabled the source side disk cache option for this AIX client. 

Seems I was mistaken the job (file system backup) is not actually running it was stuck in the scan phase for some time and has finally come back with the same error indicating to no space on the job results folder.

So I have tried running it with client side dedup and disk cache limited to 4096MB, client side dedup disabled, as well as storage policy setting and all come back with the same alert.

Description: File scan failed to write to dirchange file [/opt/commvault/iDataAgent/jobResults/2/1368/DCTmp.cvf]. Possible reasons include nonexistent path/file, hardware problems or insufficient disk space.
Source: <ClientServer>, Process: FileScan

How do I shrink this CV_CLDB ?

Interesting, you are not running an Oracle backup but a File system backup, depending of the amount of objects the Job Results folder might need to have enough space to accomodate our collect files.

Can you expand or point the Jobs Results folder to another file system within the machine? Also please make sure you are filtering the Oracle dbf files from the FS backup.

You can use this link to help you calculate the space needed for the Job Results folder (provided you are filtering the Oracle Database from FS backup)

https://documentation.commvault.com/11.25/expert/6599_job_results_directory_disk_space_calculation.html

Also I mentioned before that use of the disk cache is for limited bandwith between client and MA, I would not expect to use this setting if you are trying to protect a +-20 TB Oracle database as the MA should be as close in the network to this type of client. In short, do not use the disk cache setting and keep source side dedupe.

The job was originally setup to run with storage policy settings which is client side dedup, and that is for both oracle and File systems backups, all of which was working fine till a few weeks ago when only this server (from multiple with the same config) started running out of space on the job results folder, and to my knowledge nothing has changed in that time. We have several similar sized systems running the same OS and same backup config with no issues all there CL_CVDB's are under 20GB, so this one perplexes me some what.

Any way will log a call with the OS team to resize the volume and continue testing from there.

Below the default settings for the deduplication at the primary copy level of the storage policy and the client deduplication options:

Question is what value was defined for the disk cache? You haven’t mentioned the value before. Job results pruning does not clean the entries for the client side disk cache, once it has reached the maximum size defined it starts to write from the beginning (in a circular way) so planning the disk space is needed. You’ll have a disk cache per subclient, you mentioned a 20 TB Oracle database, it makes sense that it has reached the maximum size defined provided Oracle agent is used for protecting the database, no sure if other similar sized systems you mentioned have also a 20 TB Oracle database or not or the Max Cache size defined is different to this system.

As a guess, imagine that the database has encryption enabled, this will trigger a lot of hashes that will fill very quickly the dedupe cache on the client.

If you disable this setting, you won’t have to worry about resizing the file system for the Job Results path.