SOBR per Job?

[mkretzer]

Hello,

we are just purchasing a new backup storage with 400 TB of space (after we finally gave up REFS).

We will split this storage into 4 NTFS segments with about 100 Gb per Volume.
We also finally want to use per-VM backup chains. In the past this always lead to situations where a single merge of one backup job with 200+ VMs blocks all avaiable repository slots.

This is the main reason we did not use per-VM: Without per-VM only two slots are used and other backups can still run at the same time. Since there is still no possibility to limit the number of slots used by merges we had an idea:

Can we create a SOBR for every job (always with 4 extends pointing to different directories on each of the volumes)? With this way we can limit the tasks per Job. Or will it cause issues if there are 20 SOBR with 80 Repos in total going to the same volumes over and over again? In the past we had strange issues where the avaiable ressources did not calculate correctly and tasks "hang"...

Markus

[vClintWyckoff]

I'm not sure if we've internally tested (PM would have to answer this) that many SOBR / Extents - however on the surface my initial gut would lead me to think that your backup repository performance would be less than good. You've separated the disks logically into many volumes but they're still on the same underlying HDDs - unless you purchased 40 x 100 GB HDDs, which I am thinking you didn't. So during backup, merges etc your repository performance would be what I would think to be the bottleneck.

[mkretzer]

In fact we purchased 128 disks.
Still, the merges of our 2000 VMs can easily saturate these disks even when only some of them are running at the same time (these 2000 VMs are in about 20 jobs). That is the reason we need to limit the merges.

Without per-VM this is no problem at all, merges take 3-4 hours and have MINIMAL impact on our other backups.

I simply do not understand why there is no limiting for merges. Are we the only ones with that issue?

We really want to be able to use per-VM!!

Markus

[foggy]

Can we create a SOBR for every job (always with 4 extends pointing to different directories on each of the volumes)? With this way we can limit the tasks per Job. Or will it cause issues if there are 20 SOBR with 80 Repos in total going to the same volumes over and over again? In the past we had strange issues where the avaiable ressources did not calculate correctly and tasks "hang"...

In theory, this should work, since there are no known limitations on the number of SOBR/repositories, besides the storage capabilities.

[mkretzer]

I have another idea: If we have two directories per volume, one for full backups, one for incr and we limit the streams to the full extends we could do this safely with 8 repositories... Problem is we had a case where we had several SOBR extends on one volume and backups stalled all the time because it seems the free slots could not be calculated and the backups were always waiting for backup ressources - even with all slots avaiable.

Do you think that could work? Is it supported to have two extends on one volume (one for full, one for incr)?

I really hope such issues go away with update 3.