concurrent tasks best practice for multiple repos or SOBR?

[edison5000]

Case #05551056

I previously posted about and discovered that current Veeam advice is 2:1 (2 tasks per core), here -
servers-workstations-f49/bottleneck-det ... 81495.html

However - how does this apply to multiple repos on the same server/controller? Should concurrent tasks be evenly distributed across repos? What if those repos are part of a SOBR? Do SOBR's consider the repo load control settings? If so, how?

We tested this by keeping our primary repo settings what they were, and adding a 2nd local repo with no checkboxes selected under load control for the repo - (unlimited tasks : ) ? . Then we created a single SOBR for the two of them - and performance was identical, outside of more incrementals going to the new SOBR extent. But we figured Veeam did that because the SOBR code saw that repo2 had a lot more free space, percentage wise, than repo 1.

Doesn't really say here:

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

Thanks!

[chris.childerhose]

This site should help to explain the tasks versus core counts for Repos - https://bp.veeam.com/vbr/2_Design_Struc ... ositories/

[edison5000]

Thank you Chris. I'm afraid that does not clear up our confusion though. I read that doc landing page as well as connecting links, from it, did not help. Now, it would make more sense to me if say, when you create a SOBR, the SOBR settings took over for all the existing repos, so that it was 'in charge' of the concurrent tasking across all repos. But this it not an option in SOBR; you have to adjust concurrent tasking individually for each repo. We get that there is going to be a maximum amount of tasks that a single server can do, no matter how many repos you add, but there must be a way to figure out how to balance them.

[chris.childerhose]

Yes, as you stated, the tasks are still controlled at the individual repo level for the number. With SOBR, what plays into what repo (extent) is placement policy when sending data. SOBR should balance out things for you, and hopefully, Support answers your question. Also, another good read on this topic - https://www.veeam.com/blog/load-balanci ... guide.html

[edison5000]

Thanks. There is this, from that link you sent:

"Scale-out backup repository. SOBR is essentially a collection of usual repositories (called extents). You cannot point a backup job to a specific extent, only to SOBR, however extents retain some of settings, including the load control. So what was discussed about standalone repositories, pertains to SOBR extents as well. SOBR with per-VM option (enabled by default), the “Performance” placement policy and backup chains spread out across extents will be able to optimize the resource usage."

That's also kind of vague... I know there's the 'performance' option, but I don't think that is related to tasks. Plus also weird about this statement above is, the concurrent tasks are not adjusted in jobs, they're in the repo settings. Jobs only have data compression, retention, encryption, and maintenance. At least for agent / workstation backups, we can't use the server mode. I feel like the resource vs performance optimization you can see in the SOBR settings is really just about using the storage space that is available (vs the task-ing), but I can't tell.

[foggy]

It precisely states that 'extents retain some of settings, including the load control' - the number of tasks is the extent setting so you should keep it in mind when creating several repositories on the same server, whether SOBR is involved or not. The 'performance' mentioned here is not the load control in terms of the number of tasks assigned but rather an I/O load that is spread between the extents according to the policy rules.