+23Happy Friday everyone!
To those that don’t know, when you create a Scale-Out Backup Repository you can configure it to automatically create a new full backup if a required extent is unavailable.
I had a few conversations recently whereby I was the only one endorsing this option. So I ask, who uses it, who doesn’t, in both scenarios, why?
+21We 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. 😁
+17It 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...
+7Set to enabled but depends on free storage availability too. So on a case by case basis
+14I 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.
+8I enabled it only if I have multiple Performance tiers with enough space to receive full backup of another one.
+8Like 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.
+7We 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
+23Thanks 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.
+12I 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
+9Currently disabled until I’m sure I have room for more full backups. At this rate of growth it’s going to be tough.
+8It’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.
+20I 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!
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
