SOBR and synthetic full

[jnap]

Hello
We use Veeam in this way:
1 SOBR with 3 DDs. Each DD, configured with ddboost, has its own gateway server, which is also a direct san proxy.
If everything goes well, all vib files for each VM backup chain is stored in the same DD and synthetic full is quite good and quite fast.
But we had some issues and it happened that vib files were not all stored in the same DD (principle of the SOBR...)
The consequence is when synthetic full runs it is very slow and it also can be blocked
So my question is this one:
Is SOBR and synthetic full a good configuration couple ?
Would it be better with "incremental for ever" mode ?
Or weekly/monthly active full maybe?

thanks!

[oleg.feoktistov]

Hi Julien,

In your case I'd advise to check "Perform full backup when required extent is offline" option in SOBR Properties > Performance Tier > Advanced.
It will ensure that if extent with previous backup file is not available, Backup Server will trigger active full backup to another extent instead.
So, if it concerns Data Domain with DDBoost, I'd stay with synthetic fulls and option above enabled.
A combination with few weekly/monthly GFS backups is a go as well.
Also, check our Deduplication Storage Best Practices for more hints.

Best regards,
Oleg

[jnap]

Hello,
Thanks for this hint that i will surely try

Why do you talk about GFS backups? we currently do not use GFS but we use backup copy jobs (from DDs to windows servers in a secondary site) and we only keep some retore points. GFS option is not checked.

[oleg.feoktistov]

I see, you meant regular weekly/monthly active fulls.
Sorry, just really got used to GFS backups feature for backup jobs in v10 RTM
Yes, a combination of synthetic fulls on particular days and weekly or monthly active fulls is a great option, too.
Note, though, that if you schedule both active and synthetic fulls on the same day, only active full will be performed.

[jnap]

Hello
Thanks for your answer
I have tested the option "Perform full backup when required extent is offline" but the problem here is that veeam consider the extent "full" but not "offline", so active full is not triggered...

[oleg.feoktistov]

How much free space has each extent?
Does this problem of veeam recognizing extents as full happen occasionally with every extent or particular extent(s)?

[jnap]

32TB free on the first
18TB free on the 2nd
14TB free on the 3rd

but some jobs (before dedupe) can announce 45TB VMs
So it happens quite often to have the "unable to meet data placement policy" warning message and then the synthetic full quite often blocks or move very slowly....

[oleg.feoktistov]

Does the registry value highlighted in this article is of correct value?
I'd also suggest to contact our support team to investigate further.
Please share your case ID here.
Thank you,
Oleg

[jnap]

Hello!
Thanks for this article which can improve the way veeam dispatch data through our 3DDs SoBR
Case already opened : 03987707

I will try monday
I suppose this key needs a system reboot to be activated?

Thanks

[oleg.feoktistov]

No, as you don't actually modify Windows UI/core-relevant keys. Restarting VBR console (if opened) and Veeam Backup Service should suffice.

[jnap]

Ok, thanks,
In this case, how can i check that this new key has been really enabled into veeam?

[jnap]

Hum... i have just seen that your kb is for veeam in 9.5.0.1038 version
We already are in 9.5.4.xx (update 4)
So this new logic is already applied I think?

[oleg.feoktistov]

Ok, thanks,
In this case, how can i check that this new key has been really enabled into veeam?

Backup Service should force cache update each time extent is assigned with a new task. So, normally, you shouldn't be seeing lack-of-space-relevant warnings if your extent is estimated to have enough space for backup placement.

So this new logic is already applied I think?

The logic is made available but is not enabled by default, so that's why I asked if the key SobrForceExtentSpaceUpdate exists and is of correct value.
Thanks!
Oleg

[jnap]

Hello
OK thanks,
I have just added this key this morning and restarted the veeam services.
So wait and see now

[jnap]

Hello
This morning, no warning with "a unable to meet data placement policy" !!

[oleg.feoktistov]

Glad it worked!
Best wishes,
Oleg