First time SOBR with Azure Blob Storage

[Frosty]

Hi all,
I'm a newbie to SOBR and have set up a test backup which is copying (immediately after the backup finishes) into an Azure Storage account. It is all working fine, but I have a couple of questions about configs, data copying and storage efficiency, etc. I've looked at a bunch of YT vids and have learned as much as I can, but some of the technical detail escapes me.
Q1. does it really make any difference whether my backups are Reverse Incremental (which is what I've normally used until now) or should I be using some other approach?
Q2. when looking at the storage account, there are a lot of files appearing there which look to be like "blocks" of changed data. Is that what it's doing? i.e. only copying up the changes from each new backup?
Thanks,
Steve

[Mildur]

Hi Steve

Q1. does it really make any difference whether my backups are Reverse Incremental (which is what I've normally used until now) or should I be using some other approach?

I would use always forward incremental. But for the capacity tier with copy policy, the mode is not relevant. Reverse incremental is also fine.

Q2. when looking at the storage account, there are a lot of files appearing there which look to be like "blocks" of changed data. Is that what it's doing? i.e. only copying up the changes from each new backup?

Correct, only changed blocks are offloaded after the first offload was done. In the object storage, you won‘t have „files“, only blocks of this backup files.

[veremin]

The source backup mode does not matter, you can stick to whatever one you like: be it forward or reversed incremental method. Capacity Tier is similar to ReFS feature, meaning only new (not copied previously) blocks are offloaded to object storage. You can find more information about it here.

Thanks!

[MLusk]

That link is for index structure locally, the "ArchiveIndex" folder.
This one is for capacity tier blocks structure on your object storage:
https://helpcenter.veeam.com/docs/backu ... ml?ver=110

[Frosty]

I've implemented SOBR into Azure Blob Storage and so far it is mostly straight forward. I have switched over to using Forward Incremental and am doing some weekly Synthetic Fulls as well. Data is being copied over ... but ...

One job ran, with 4 x VMs in it, and one of the VMs didn't offload correctly, showing these error messages in the job output:

13/05/2022 3:01:09 PM :: Failed to offload backup. Error: Failed to retrieve certificate from DefaultEndpointsProtocol=https;AccountName=xxxStorageAccountNamexxx
13/05/2022 3:01:10 PM :: Failed to retrieve certificate from DefaultEndpointsProtocol=https;AccountName=xxxStorageAccountNamexxx
13/05/2022 3:01:10 PM :: Processing finished with errors at 13/05/2022 3:01:10 PM

The really odd thing is that this happened last Friday afternoon and this morning Monday the job is still showing in the Running list. I have right-clicked on the running job, to select Stop Session, but it is still there.

I am a bit concerned that this might keep happening and I am unsure as to the root cause. I did implement a bandwidth limitation in our firewall, so that the backup server uses no more than 80% of our available bandwidth when offloading the data. Am wondering whether "dropped packets" as a result of that throttling might have caused it.

Any suggestions? One contact of mine suggested limiting the number of Azure Concurrent Tasks via: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\ and setting Dword Name = AzureConcurrentTaskLimit = 4 (or maybe less?)


Steve

[Frosty]

Just discovered that pressing <F5> refreshes the list of Running jobs and the Completed-but-Failed offload-to-object-storage jobs are no longer showing there.

But my question (previous post) still stands around the likely cause of this ...

Plus I guess I am curious to know whether this is truly self-healing and whether the daily catch-up will really fix the issue and correctly offload the files to Azure. It looks like it does, but it isn't really clear to me from the job History that it has "caught up" (even though it looks like it might have, because when I look at the Object Storage for that job and I see a correct number of restore points there).

[Mildur]

Hi Stephen

Please open a case for the question "I am a bit concerned that this might keep happening and I am unsure as to the root cause."
Our Support is trained to find the "root Cause" of technical issues.

Instead of controlling the speed in the firewall, you could use veeam to limit the used bandwidth.
https://helpcenter.veeam.com/docs/backu ... ml?ver=110

[Frosty]

Thanks Mildur -- what an excellent idea -- I'd forgotten that Veeam can throttle bandwidth!
If I can't get on top of the issue, I'll log a ticket for sure.