I'm trying to understand where is processed file indexing in a backup job.

I have a 7TB file server (3TB used). The backup job was configured at 1st without file indexing. I have activated file indexing some days ago.

1st. time, Incremental, it tall 1 hour 51 minutes to index the guest files.
2nd time, Incremental, this operations took 3 hours 30 minutes
Last night, Incremental, the operation has been running for 4 hours and 25 minutes and is not finished yet.

VMs are on Nutanix. We have virtualized proxies in the same room/same switchs, different subnets. Backups are written to a Dell DR dedup box.

Where could be my bottleneck here ? What my explain why it went from 1:51 to over 4:30 ?

Is there any deep-dive doc on this matter that would help me understand the process ? Because if at some point Veeam need to read previous backup data from the Dedup box to implement/update the file index, this might easily explain the problem...

I have obviously read the document you propose. It is not quite extensive on details. Or if it is, I understand that Indexing is handled by the source server (the file server) and then, the Backup Server is just proceeding to zipping and unzipping the file whenever required.

This does not explain why the indexing process time is doubling at each occurrence (I guess. 5:40 for now at third occurrence and ongoing)

Bottleneck is shown as source, as it would be expected as the backup job is finished since a long time. Indexing is the only running task within the job.

I kind of expected that, which means I won't be able to help you a lot further without additional information. Can you log a support call? Our engineers can review all of your logs and see where there are potential issues.

Please post the support case ID here, and when they came back to you let us also know what the solution is. It will help other people on this forum

Hi together,
in my case, indexing speed is limited by the speed of a single CPU core.
As far as I can see, the indexing process just utilizes 1 core. Depending on the current CPU load, the indexing time may vary.

As stated by support team in case #02112247 there is no possibility of optimizing this behaviour.
Therefore my feature request: Multiple threads for the indexing process.

Use case: The incremental backup of our multi TB Fileservers takes just some minutes. The incremental indexing process takes up to 5 times that backup time.
Of course I understand that multiple threads would put load on the guest VM. But with proper priority settings for this process, that should not be an issue.