We enable it for all our client VCC backups.  It is my recommendation and part of any design.  You just never know when a server could go down. 

It is a useful function.

We are using it. The only thing is not to create too big extents. Otherwise a lot of full backups can be triggered...

I enabled it only if I have multiple Performance tiers with enough space to receive full backup of another one. 

Set to enabled but depends on free storage availability too. So on a case by case basis

Like everything...it depends.  That said, I don’t typically enable it as I’d rather address the failure than have it cover the failure and create new fulls.  Then once I have it addressed, retry the job and get a good backup.

We don’t use it. Like Derek says we’d sooner address the failure and resume backups.

That said in an ideal world I’d probably enable it if I was a single site as opposed to an MSP

I would say it depends on the sizing but normally I disable the option. If one extent goes offline I would rather manually decide what to do instead of having Veeam create new full backups.

Thanks for all of the replies so far!

For those that don’t enable this, how do you avoid RPO violations? Are you backed by a 24x7 service desk? My main concern is if this happened on a Friday evening and nobody notices the extent is down until Monday.

I disable it nearly always. Why? In my opinion it depends on the size and the quantity of the exents. In the setups of our customers that are using a SOBR, they only have 1 to 3 extents. Why? Often because they didn’t had enough storage on there first extent and was not easily to extend. Therefore adding a new extent is a simple solution. We first try to analyse the problem of the extent and try to solve it and if needed, we enable it, but not by default, because the availble extents have mostly not enough free space to put all the fulls on it. But it all depends which extent is failing, the one with the biggest size or not… In my opinion, the more extents in a SOBR, the bigger the chance I would enable the option because then there is less a problem.

For the VCC as @Chris.Childerhose mentioned. I have to disagree on this one. Also here I don’t enable and first analyse the problem. If not, all those impacted tenants (and that could be a lot - in a SOBR setup you never know for sure) would create a new full at one evening/night. That could deliver a lot of traffic for our VCC infrastructure, also still running jobs the day after for the customer (not every customer has a high upload bandwidth available). If the day after the issue could have been easily fixed, all that traffic (even not ended in a lot of cases) and storage would have been for nothing. That’s my personal idea, and also it depends of the available size, number of extents, how many customer being impacted, their upload bandwidth in combination with the storage being uploaded, …. You don’t know all the parameters beforehand to make the correct decision : it’s a bit like being in a disaster scenario, an automatic failover is also never being engaged, first analyse, take the decision and failover or wait/resolve the issue

Currently disabled until I’m sure I have room for more full backups. At this rate of growth it’s going to be tough. 

It’s enable for me. Why? It creates a resilency if you lost a repo (physical server) you can continue to backup your data. Well tested and approved 2 week ago, a mother board of one server fried. Don’t put all your eggs on the same basket.

It’s always about RPO/RTO and money . Don’t put all your eggs on the same basket.

I do not enable. We aren’t ‘hard & fast’ needed to cover RPOs, and I don’t use SOBR with multiple extents. I use them to cover when I need to make changes to an extent & can more easily evacuate backups to a ‘spare’ extent, which is rare (only done once in several yrs of using). I have multiple copies of backup data on multiple arrays, so I generally have needed data and at least close to the RPO we (IT) have determined for our systems.

Cheers!