Scale Out Repository Usage - Always Same Extend

[sturmtr]

Hello all,

We have a brand new Veeam installation in our new Vmware environment.
We have configured a scale-out repository using 2 DD9900 with data locality option.
We have noticed that all of the 18 backup job is using the same repository extend.
When we seal one of the extend, backups switches to other extend without problem.

We wanted to understand why every job is using the same extend.
Although this is a non busy environment I think 3-4 backup are running at the same times during nigth.
Is there a way to change this behaviour?

[RomanK]

Hello sturmtr,

From this guide page:
If you set the Data locality policy for a SOBR, all backup files that belong to the same backup chain are stored on the same extent of the SOBR. The Data locality policy does not put any limitations to backup chains. A new backup chain may be stored on the same extent or another extent.

Most probably there are old chains and they continue using the same extent. Have you tried to create a new chain? Would it still use the same extent?

Thanks.

[sturmtr]

Hello,

When I clone a job in order to create a new chain or even create a job from scratch, they have been writing to the same extend.
At the moment all jobs (18 of them) are going to the same extend somehow

Maybe when we create more jobs it will switch to other one but I wanted to know whether we can change this behaviour.

Regards.

[sturmtr]

Hello,

Any idea?

[RomanK]

Hello sturmtr,

The extent selection algorithm works like this:
1. filter extents in the maintenance mode and sealed mode
2. filter extents with the unavailable state. This process changed a bit if there is an extent created last 60 minutes.
3. filter by SPBR policy locality or performance.
4. then extents are filtered by the free space. On this step, the extent could be busy with other tasks. It must have other resources than free space to be selected otherwise it would be ignored. For example, if maximum concurrent tasks are limited and there is no free slot.

Try to check all these steps. If nothing, creating a support case and sharing the logs would be the better approach. In the logs all processes should be written.

Thanks

[sturmtr]

Thank you for your reply.