Questions about SOBR pre-allocation logic during Linux Agent Backup Job pre-processing

[alwubfje]

Hello,
I have several questions about the pre-allocation (free-space) validation performed during the pre-processing stage of a Linux Agent Backup Job, when using a SOBR repository.


1. Logical backup size used for SOBR pre-allocation
Our understanding of the SOBR pre-allocation logic is as follows:
・The capacity validation does not take into account Data Domain deduplication or compression.
・Instead, it evaluates whether a backup can fit entirely into a single extent based on the logical backup size (before deduplication).

Question 1:
For Linux Agent volume-level backups, is it correct that this logical backup size corresponds to the used data size of the source volume?
For example, when job statistics show values such as:
50 TB (20 TB) for the source volume,
does SOBR use 20 TB (used size) rather than 50 TB (total volume size) for pre-allocation estimation?


2. Estimation logic for different backup types
Our current understanding of SOBR pre-allocation estimation for Linux Agent volume-level backups is:

・Initial full backup:
Estimated size = used data size of the source volume

・Subsequent full backups:
Estimated size = 100% of the previous full backup file (VBK size)

・Incremental backups (including standard incremental and synthetic full schedule):
Estimated size = 10% of the previous full backup file (VBK size)

Based on this estimated size, SOBR checks whether a single extent has enough free space.

Question 2:
Is the above understanding correct?

Any clarification would be greatly appreciated.
Thank you.

[HannesK]

Hello,
and welcome to the forums.

What problem do you try to solve and does this maybe answer it? And if not... what is the exact setup that you have? Multiple DataDomains in a Scale-Out Backup Repository (SOBR) or did you do a mix of different repository types? In general, the software always tries to keep one backup chain on one extent and the initial placement logic is the most important one.

Best regards
Hannes

[alwubfje]

Hello Hannes,

Thank you for your response.

Please find my answers below.

First, regarding the configuration:
- We are NOT using multiple Data Domains in the SOBR.
- Instead, we are using a single Data Domain, and multiple MTrees are configured as performance tier extents.
- We are also NOT mixing different repository types.

Regarding the issue we are trying to solve:

When we started the backup job, it failed during the pre-processing phase (before data transfer) with a "repository out of space" error.

As mentioned in my original post:
- The backup source volume size is 50 TB (Used: 20 TB).
- The available free space on the Data Domain (SOBR) was 19 TB.

Our goal is to understand the capacity validation logic during the pre-processing phase, so that we can avoid this error in advance and ensure successful backup execution.

Additionally, since Data Domain provides strong compression and deduplication, we expected that the backup could still be stored even if the used data size (20 TB) is slightly larger than the available capacity (19 TB).

We would appreciate your clarification on how the initial placement and capacity check logic works in this scenario.

Best regards,

[HannesK]

Hello,

Instead, we are using a single Data Domain, and multiple MTrees are configured as performance tier extents.

okay, and what is the idea of this? Because it feels like it over-complicates things but I'm not a DataDomain expert.

The backup source volume size is 50 TB

yes, and the link above mentions in the "backup size estimation" section "The size of the first full backup file is equal to 50% of source VM data.", which would be 25TB. And 25TB is larger than the 19TB free space.

How much free space do you have on the Data Domain in total? Would it be an option to put everything into one mtree?

Best regards
Hannes

[alwubfje]

Hello Hannes,

The reason why we have configured multiple extents (MTrees) in the performance tier of the SOBR is for load distribution purposes. Specifically, we aim to avoid a situation where multiple backup tasks are executed concurrently on the same extent, which could degrade processing efficiency.

In this case, the backup target is not a VM, but a volume of a physical server where Veeam Agent for Linux v6 is installed. As mentioned earlier, the documentation you referenced does not describe the estimation logic for pre-processing in such a scenario, which is why I am asking these questions.

As already stated, the available free space on the Data Domain is 19 TB in total. Each MTree does not have dedicated or fixed capacity; they are simply logical containers used for load distribution. When used as repository extents, they consume space from the overall free capacity of the Data Domain.

Therefore, consolidating everything into a single MTree is not an option for our design.

Best regards,
John

[HannesK]

Hello,
if all extents have 19TB free, then you can try the SOBRFullCompressRate registry key. There is an old post that mentions it with 25% as default but it's 50% today.

If the key works for you, then I would ask the documentation team to remove the "VM" and I cannot imagine why the logic only applies to VMs.

Best regards
Hannes

[alwubfje]

Hello Hannes,

Thank you for your explanation.

From Veeam Support, we have been informed about registry keys that adjust the capacity estimation during the pre-processing phase for subsequent full and incremental backups.
(For safety reasons, I will not include the exact key names here, but the logic is to control what percentage of the previous VBK/VIB size is used for estimation.)

In this context, I would like to clarify the following points regarding the registry keys you mentioned:
1.　Do the registry keys SOBRFullCompressRate and SOBRIncrementCompressRate only affect the capacity estimation during the pre-processing phase of the initial full backup and initial incremental backup?

2.　Is the allocated space based on the following criteria?
・Full backup: 50% of the used backup source data
・Incremental backup: 10% of what exactly?
(Is it based on the previous backup size? If so, which one?)

We need to ensure that the initial full backup and the first incremental backup do not fail during the pre-processing phase. Therefore, your clarification on the above points would be greatly appreciated.

Best regards,
John

[HannesK]

Hello,
can you please share the support case number. It makes little sense that support and I do duplicate work.

SOBRFullCompressRate is for all full backups (which is normally one, but I have also seen customers doing regular active fulls) and SOBRIncrementCompressRate is % of previous VBK. But VIBs should go to the same extent anyway because otherwise merges would be going through the gateway server because it's a different extent / file system (another reason why I would avoid multiple extents on the same hardware).

Best regards
Hannes

[alwubfje]

Hello Hannes,

Thank you for your response.

The support case number is #08095869.

Best regards,
John

[HannesK]

Hello,
okay, I don't speak Japanese, but it feels like all options are on the table and you just need to apply the SOBRFullCompressRate registry key. I will leave it to support to continue.

General recommendation: apply the KISS principle. That means, one extent per physical data domain instead of splitting it into chunks. It won't help you with the current issue, but can make your life easier with the next hardware refresh.

Best regards
Hannes

[alwubfje]

Hello Hannes,

Thank you for your previous response.

I was advised by Veeam Support to follow up on this topic in the R&D forum, so I would like to ask additional questions regarding the registry keys and SOBR pre-allocation behavior.

■ Q1: About the registry key "SobrReserveExtentSpacePercent"
I understand that this key is used to reserve space (e.g., for metadata) on extents.
However, according to Support, there is no public documentation describing:
- When the reservation is made (e.g., job start timing)
- How long the reserved space is kept

Could you please share any publicly available information about the following, if available:
- How to check the currently reserved space amount
- What is the maximum possible reserved space (e.g., based on Max Concurrent Tasks or other factors)

■ Q2-1: Difference between registry keys
How are the following keys different:
- SOBRFullCompressRate / SOBRIncrementCompressRate
- SOBRFullSizeEstimatePercent / SOBRIncrementSizeEstimatePercent

■ Q2-2: Usage timing of CompressRate keys
Are "SOBRFullCompressRate" and "SOBRIncrementCompressRate" always used during the pre-processing estimation for every job execution (full/incremental)?
(We were informed that SOBRFullSizeEstimatePercent / SOBRIncrementSizeEstimatePercent are applied only from the 2nd run onward, because they rely on previous VBK/VIB files.)

■ Q2-3: Calculation logic
Could you provide the calculation logic for each registry key?
(For example: previous VBK size × (configured value ÷ 100))

■ Q3: About "SOBRFullSizeEstimatePercent" and "SOBRIncrementSizeEstimatePercent"
Support explained that these values are applied from the 2nd full/incremental backup onward.

Is the “2nd run onward” determined per *backup job*, not per protected data?

For example:
- If Job X (already run once) and Job Y (never run) back up the same volume,

Is the following understanding correct?
- Job X: estimation uses the registry keys from the next run
- Job Y: estimation does not use these keys on the first run

I would appreciate your clarification.

Best regards,
John

[HannesK]

Hello,
let's not over-complicate things... you try the key and let me know the result.

Best regards
Hannes

[alwubfje]

Hi Hannes,
I would like to share an observation from my testing.
During the initial full backup, I observed the following behavior:

SOBRFullSizeEstimatePercent did not seem to take effect, which is expected since the estimation logic relies on the previous VBK file size.
Instead, the SOBRFullCompressRate value appeared to be applied.

Based on this, it seems that during the initial full backup pre-processing, the estimation works as follows by default:

For VMs: 50% of the VM size
For Agent backups: 50% of the backup source data size

It is still unclear whether this "backup source data size" refers to the total size or only the used space.
Separately, could you also help clarify my original questions (Q1–Q3)?
I would really appreciate your input on those as well.

Best regards,
John