Skip to main content
commvault.com commvault.com
Question

Recurring Backup Bloating and Job Stalling

  • January 29, 2026
  • 4 replies
  • 31 views
M
Novice
Forum|alt.badge.img+1

Incremental Backup Converted to Full (7.5TB+) following Synthetic Full Completion

 

Problem Description

A recurring issue has been identified where incremental backup jobs significantly increase in size (bloating from ~1.5GB to 7.5TB+) specifically after a Synthetic Full backup is performed. In the most recent instance, the backup remained in a "Running" status for over 10 days. While the job continues to progress slowly due to limited bandwidth between the Cloud source and the on-premises Media Agent, the root cause is a logic failure in the backup chain.

Technical Analysis

 

Automatic Job Conversion: Commvault automatically converts an incremental backup to a full backup if it cannot establish a valid baseline or if the previous cycle did not close correctly.

Cycle Disruption: A backup cycle starts with a Full/Synthetic Full and ends before the next Full. If the Synthetic Full (DASH Full) fails to properly sync its metadata index or deduplication signatures due to network latency, the subsequent incremental job initiates a "Scan All" and backs up the entire dataset to ensure data integrity.

Resource Stalling: The bloated job consumes all available streams for that client, causing subsequent scheduled backups to fail with error 19:2586 ("Another backup is running").

 

Next Steps?

4 replies

S
Vaulter
Forum|alt.badge.img+12

Hi ​@Michael G ,

Good day!

Is this a File system agent ?

The incremental after synthetic once in 30 days will start a reconcile backup.

Ref : https://documentation.commvault.com/11.40/commcell-console/backup_reconciliation_03.html

The size of the incremental will be same as Full but it wont copy that much data.

Regards,

Sureshkumar S

M
Novice
Forum|alt.badge.img+1
  • Michael GNovice
  • Author
  • Novice
  • February 1, 2026

The incremental backup job after Synthetic Full is taking a longer time due to true up?

 

media-agent\FileScan.log

 

21260 59b4  01/18 20:00:16 159788 CScannerOptions::LoadConfiguration(204) - TrueUpSkipped [No] TrueUpEnabled[Yes] TrueUpForced [No] DaysToRunTrueup[30] JobsToRunTrueup[0] TrueUpSkipAfterSynth[No] SkipDC[No]

21260 59b4  01/18 20:00:45 159788 CWindowsTrueUpJobHandle::InitializeTrueUpJob(209) - +++ 

21260 59b4  01/18 20:00:45 159788 CWindowsTrueUpJobHandle::InitializeTrueUpJob(286) - True-Up ChangeTime Check Registry Key [No] Scanner Configuration Bag [No] FileServer Scan [No] ChangeJournal [No] Optimized Scan [No] Archive Bit [No] Preserve Access Time [Yes] Use CTime [No]

 

Add the below keys on the media-agent to disable true-up and verify the incremental backups running after a Synthetic Backup job?

 

Setting name:    bSkipTrueUpForIncrAfterSynthFull

Category:    FileSystemAgent

Type:    Boolean

value:    1    

Setting name:    nSkipTrueUp

Category:    FileSystemAgent

Type:    Boolean

value:    1

 

We will proceed with applying the suggested registry keys to disable the True Up process. We understand that while this will mitigate the performance impact, it removes a layer of data integrity verification following the Synthetic Full jobs. Right?

​However, upon reviewing the FileScan.log provided earlier, we noticed the following status:

Optimized Scan [No]

​Since the lack of Optimized Scan forces a traditional recursive scan (which explains the significant delay), we would like to address this root cause as well:

​Why is the Optimized Scan inactive? Is there an indication of corruption in the DCDB (Data Classification Database)? Does reactivating the Optimized Scan require a simple restart of the Commvault services on the Client/Media Agent, or is a database reconstruction required?

 

​We would prefer to fix the Optimized Scan mechanism to ensure long-term performance stability rather than relying solely on bypassing the True Up check.

 

M
Novice
Forum|alt.badge.img+1
  • Michael GNovice
  • Author
  • Novice
  • February 3, 2026

 

1. The Role of the "True Up" Process

True Up is a data integrity security mechanism that Commvault triggers automatically during the first incremental backup following a Synthetic Full. Its purpose is to scan the source disk and verify that the "artificial" full backup created synthetically actually matches the current reality of the file system.

While we have the option to disable this feature, it is important to understand the trade-off: disabling it reduces the long-term reliability and consistency of the backed-up data.

 

2. The CIFS Scanning Bottleneck

Because we are backing up via a network share (CIFS), Commvault is forced to perform a Full Scan. In our environment, this process exceeds 12 hours and triggers the errors seen in the logs.

Unfortunately, the Optimized Scan suggested to us will not resolve this. Since Commvault does not have direct, block-level access to the file system of the storage server, it cannot utilize the change-tracking drivers required for an optimized scan.

 

3. Performance Analysis

The "Read" speed is extremely slow. Support has confirmed a significant bottleneck where the storage is failing to stream data to the MediaAgent (MA) at a sufficient rate.

 

4. Recommendations

Commvault's best practice for heavy CIFS workloads involves a distributed architecture.

  • Immediate Scale-Out: Deploy a minimum of two Access Nodes to distribute the processing load.

  • Infrastructure Shift: My professional recommendation is to either migrate to HyperScale or, at the very least, adhere to best practices by adding an additional MediaAgent to eliminate the current bottleneck.

 

Apart from this, do they have any other suggestions to resolve this issue?

S
Vaulter
Forum|alt.badge.img+12

Hi ​@Michael G ,

Trueup cannot be skipped its inbult default now.

The key wont have any effect | its a discontinued key.

Optimized scan is not available for CIFS backup.

Regards,

Sureshkumar S

 

Terms & ConditionsCookie settingsAccessibility statement