V12 SOBR Rebalance epicness

[mkretzer]

After more than one week of V12-bashing i want to end the week on a positive note:
V12 SOBR rebalancing is epic (even if it should run entirely in the background)

We were able to move about 26 TB of backups (6170 backup files!) from a overfilled repo to more empty repos in 9 hours while other backups to the same drives worked perfectly.

I am wondering one thing: Is there a limit how many SOBRs can be created? I am thinking about creating a SOBR for every backup job (just different folders on the same drives). That would make the missing background functionality much less problematic.

[HannesK]

Hello Markus,
good to hear, thanks for sharing!

Yes, the background rebalance is something we need to work on.

Best regards,
Hannes

[Gostev]

You can have max 3 SOBR with Enterprise edition, with VUL or Enterprise Plus it's unlimited.

But the more SOBRs you have the longer backup infrastructure rescans will take for the resource scheduler. Meaning it will take longer for jobs to start processing machines. Normally this should not be a big deal as this doesn't affect actual processing performance, but some customers are obsessed over this 1-2 minutes delay (there is a big thread with complaints about this here).

I vaguely remember seeing that a couple of weeks ago QA was going to test a scenario for some VCSP who wanted to create the dedicated SOBR per client so something well above 100. If any PM is involved please update us here on the progress.

[HannesK]

ah sorry, I missed to answer the "number of SOBR" question: I would clearly avoid it! Service providers do it historically because it's the only way to have one bucket per customer in capacity tier and be able to calculate disk space usage with REFS / XFS block cloning for chargeback. I also remember a discussion about scalability for the Cloud Connect scenario. But we don't have Cloud Connect here.

There is no hard limit with number of (scale-out) repositories. With hundreds of branch offices, that's something we see working. But I would still avoid it in your scenario, because you somehow need to move the data. The move is actually a copy even on the same file system in V12 (planned to be fixed). So you would create a huge amount copy IO for an "ugly hack".

[mkretzer]

Ok, keeping it for now! Thank you Hannes and Anton!

[cdubus]

In "https://www.veeam.com/veeam_data_platfo ... son_ds.pdf"

"With Enterprise edition, users can create two Scale-out Backup Repositories with three
active extents and unlimited inactive extent (placed in maintenance mode). VUL and
Enterprise Plus edition have no limitations on the number of repositories or extents."