SOBR Placement - Improper extent

[RobMiller86]

Case: 07129564
VBR 12.1

We are soon replacing our primary SOBR with new servers and moving them to Linux, but in the meantime, I'm trying to get by until the drives arrive for the new servers. In short, VBR seems to make some poor decisions with placing new backup files on a SOBR. We are using Data locality, and per machine backup files.

Extent 1: 152.8TB with 83.7TB free
Extent 2: 87.3TB with 17.5TB free
Extent 3: 50.9TB with 3.1TB free

All 3 extents have been up, haven't been rebooted. Backup copy job just placed a new set of backups, only 500GB, on Extent 3, 3 days ago. I just rebalanced and now we need to rebalance again, stopping all backups in the process. What would cause VBR to select this extent for a new backup copy job? It doesn't seem to be following what I am reading here: https://helpcenter.veeam.com/docs/backu ... ml?ver=120

Now we do have multiple backup jobs added to a single copy job. But I don't think it's supposed to keep all objects together in a single copy job, when copying to a SOBR. Plus, there are other jobs in this copy job on other extents anyway. So why VBR placed them here is mystifying.

I would think as we add more backups, it would intelligently place them, but instead it seems to just randomly pick an extent. I know that isn't the case, but it doesn't seem be operating as per the guide.

[RobMiller86]

My response from support doesn't seem to make much sense.

I understand you have some questions regarding your SOBR configuration and data placement.
I noticed you said you were using data locality. This is why the files are being placed as they are. Data locality will prioritize grouping files from the same chain together over other factors, such as available space.
For that type of file placement, you'd likely want to look into using "performance" as the placement policy.

Data locality keeps fulls and incrementals together on the same extent. I have no idea why or how a brand new copy job, from a different SOBR to this one, without having any existing backups for VMs in the copy job on this SOBR, would choose the extent with the lowest amout of free space both in terms of percentage and actual storage. Doesn't using per VM backup files mean that you have separate chains for each VM anyway? I don't understand how splitting my backup fulls and incrementals apart on different extents using "performance" has anything to do with VBR's logic with placement for a new backup file, copied or not.

If it's a new backup, either a Backup Job or a Backup Copy job, to a SOBR in either mode, it should select the SOBR extent with the greatest amount of free space as a percentage shouldn't it?

From the guide:

Extent Selection

To select an extent for backup file placement, Veeam Backup & Replication checks the following conditions:

1. Availability of extents on which backup files reside. If some extent with backup files from the current backup chain is not accessible, Veeam Backup & Replication will trigger a full backup instead of incremental (if this option is enabled). For more information, see Adding Backup Repository Extents.
2. Backup placement policy set for the scale-out backup repository.
3. Load control settings — maximum number of tasks that the extent can process simultaneously.
IMPORTANT

If a Services Provider uses an extent as a cloud repository, Veeam Backup & Replication compares the percentage of active tasks over the extent task limit and selects the extent with the least load over the extent. For example, if the A extent tasks limit is 5 tasks, and currently 3 tasks are active, and the B extent tasks limit is 30 tasks, and 10 tasks are currently running, Veeam Backup & Replication selects the B extent. If there are several extents with equal percentage values, Veeam Backup & Replication checks a disc space and selects the best suitable extent based on this check. For example, if there are extents with the same percentage of running tasks, Veeam Backup & Replication compares their disk space and selects the extent with the least disk space occupied.

4. Amount of free space available on the extent — the backup file is placed to the extent with the most amount of free space.
5. Availability of files from the current backup chain — extents that host incremental backup files from the current backup chain (or current VM) have a higher priority than extents that do not host such files.

It seems to use more than just free space to determine which extent to use. Although it also seems a little dicey to select based on task limits. That makes it sound like if you happen to be at your task limit due to running jobs when another job kicks off to write a new backup, it's going to pick the extent with less active tasks instead of more free storage. Regardless, Extent 1 above is set to 16 tasks, and 2 and 3 are both set to 12 tasks. I can't determine why VBR would choose to place this new copy on Extent 3.