Comprehensive data protection for all workloads
Post Reply
Posts: 54
Liked: 1 time
Joined: Oct 12, 2012 12:28 am
Full Name: Mike Godwin

SOBR size of individual repositories

Post by 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?

VP, Product Management
Posts: 5660
Liked: 2461 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler

Re: SOBR size of individual repositories

Post by 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.

Veeam Software
Posts: 5918
Liked: 1739 times
Joined: Jul 26, 2009 3:39 pm
Full Name: Luca Dell'Oca
Location: Varese, Italy

Re: SOBR size of individual repositories

Post by 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.
Luca Dell'Oca
Principal EMEA Cloud Architect @ Veeam Software

vExpert 2011 -> 2020
Veeam VMCE #1

Post Reply

Who is online

Users browsing this forum: DMiller65, DonZoomik, gmajestix, Google [Bot], Onur94, Vladitar and 59 guests