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

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?
tsightler
VP, Product Management
Posts: 6011
Liked: 2843 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

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.
dellock6
VeeaMVP
Posts: 6137
Liked: 1928 times
Joined: Jul 26, 2009 3:39 pm
Full Name: Luca Dell'Oca
Location: Varese, Italy
Contact:

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

@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
Post Reply

Who is online

Users browsing this forum: Amazon [Bot], justin.hendren and 218 guests