SOBR size of individual repositories

[mikegodwin]

With SOBR are there any requirements regarding the size of the individual backup repositories compared with the size of the data being backed up? For instance, if I have a single VMDK that is 5TB in size, but all of my individual repositories are 2TB volumes, will SOBR handle that and split the data across different individual repositories, or do the individual repositories need to be able to handle the largest .vbk file that might be created?

[tsightler]

No, SOBR will not deal with that, it does not split an individual backup file across multiple extents. The general recommendation from the field is that any extent should be at least 3x the size of the largest VBK that is likely to be created. In other words, if you have a 5TB VM, that is likely to create a 2.5TB VBK (assuming at least 2x data reduction), then I'd recommend that the smallest extent would be at least 7.5TB (larger is even better).

You definitely don't want to go overboard and create tons of very small extents, this simply will not work well. Whenever I talk with customers about their SOBR designs, the rule is always fewer, large extents is far better than more, small extents. I also much prefer when a single physical/virtual server acting as a repo = single extent, but I do understand that this isn't always possible as some storage systems have volume limits that may require aggregating extents on the same server.

[dellock6]

I was honestly even more aggressive in this design myself, and even if I never suggested a fixed number, following Tom's advice I'd go for even bigger numbers, like 10x. The reason behind this is that any large virtual machine entering the SOBR if it's size is a large percentage of the extent size, it will create issues with the placement algorithm. I'm NOT saying that the algorithm cannot place the VM correctly, rather than calculations about free space will be impacted by this. In Tom's design, that machine alone will change the free space calculation of an extent by 33%, which is a massive number IMHO. I'd go as Tom said with fewer large extents, planning to have a decent number of VMs stored in each extent.