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,