Hi @Egor Skepko ,

The issue might be the DC DB.

Scan completed, ScanType=eDC]

Have you tried different Scan Type?

https://documentation.commvault.com/2023e/expert/file_scan_methods_for_windows_file_system_agent.html

Best Regards,

Sebastien

@Sebastien Merluzzi We are using Optimized Scan because of the large nummbers of file, here is the log of last week when its completed on time, the same type of scan. 

@Egor Skepko ,

Can you try another type and then change back to Optimize Scan?

Best Regards,

Sebastien

@Sebastien Merluzzi Do you want me to run back with anoyhrt type scan? Or only change it and inmiddetly changew back? 

What type do you recommend and what wil be inmpak on the backup by changing? 

@Egor Skepko ,

Can you change to Change Journal, run a Backup and then change back to Optimize Scan and run a Backup.

https://documentation.commvault.com/2023e/expert/file_scan_methods_for_windows_file_system_agent.html

@Sebastien Merluzzi Wat wil be impact on the systeem after changing to journal scan? Wil be more load on ? 

@Egor Skepko ,

no impact but this type will take longer, this will also reset the DC DB.

So once you change back to Optimize Scan hopefully it will work as expected.

@Sebastien Merluzzi The changing to journal scan and back did not helped, I see that the scan completed at 5:40. 

HI @Egor Skepko ,

I checked the log again and investigated:

1984  3848  04/16 02:00:07 4367861 CFind::IsJobQualifiedForRunningTrueUp(135) - TrueUp is enabled via subclient Option i0], TrueUp command line i0], TrueUp reg r0], Incremental after Synthetic Full u1]

1984  291c  04/16 08:30:38 4367861 CFileScanJMProgressReportTask::Execute(55) - Total Scanned items count did not change in last 9060] seconds. Current Count: Folders l14504029] , Files F20155885] , Total T34659914] 

So it's not an issue but an expected feature that syncs up the index with client, and makes sure there is no data mismatch:

https://documentation.commvault.com/2023e/expert/reconciling_backups_of_windows_file_system_subclients.html

Also, please see article below: 

True-up is a special function that validates that the synthetic full is not missing data. Consider that file share backups use modified time to detect changed files, if there is a blimp in the system and that file is unavailable during scan, then it will never be picked up by an incremental or synthetic full ever again. So true-up runs on the first incremental after a synthetic full as extra protection to make sure all files are properly captured. The time it takes is dependent on the number of objects / files to scan across the original source.

Best Regards,

Sebastien

@Sebastien Merluzzi Thank you to investigation, yes we have alot of file and folders to scan. How can we fix this issue, because till 2 weeks ago there was no probleem, the backup running now from 20:00 till 8:00 but even yestoday was it not enough. Olso i see that IFIND.exe using alot of memory, can we reduce it? 

Here are the logs from yestoday.

I have created case at commvault : Case 240419-460

@Egor Skepko ,

As explained, it is not an issue. Did you check the link to our documentation and the key you can add?

Now you logged a case we will check and confirm.

I see you had a case for that exact/similar issue (230210-214) where this was discussed with my colleague.

@Sebastien Merluzzi No i didnt check the document for addition setting, we are added IFIND-AffinityMask to the client

Can you link the documents? 

@Egor Skepko 

I see you had a case for that exact/similar issue (230210-214) where this was discussed with my colleague.

@Sebastien Merluzzi, Yes, but the additional setting didnt not reduce the usage of RAM. Maybe is best to change to Block-Level backup Options? That wil reduce scan time and maybe RAM usage ? 

@Egor Skepko 

I was talking about the ley in my link above from our Doc.

@Sebastien Merluzzi Oh you mean that document, no didnt added any settings.

VolumeFilters  - The subclient configure to backup only volume  U:/ so this setting wil not needed i guess

And another 2 settings from the document i dont really know about. 

@Sebastien Merluzzi This issue is solved and the case are closed. 

@Egor Skepko 

Can you share what has been done or what did you do to fix this?

@Sebastien Merluzzi I created case 240419-460 at commvault, the solution is there.

@Egor Skepko

I already checked and see the resolution we have provided

There is a way to expedite the process of reconciling backups of Windows File System Subclients in Commvault. You can achieve this by using the qcommand.

But the last email says I didnt do any changes en seems the backup working correct again,

I wasn’t sure , so, you created that xml, ran the script to update “Reconcile Backup”?

@Sebastien Merluzzi Hmm i can remember that i created new client group with the agent and added xml file on the client. I think that was re right solution. I cant remember why i wrote that "i didnt did any changes”

@Egor Skepko , ok, that’s good.