Config Backup to SoBR

[SteelContainer]

Hi there,

Any idea if we will be able to do a configuration backup to a scale out backup repository in future?

Thanks!

[Shestakov]

Hi Cullan,
We don't usually promise features and share ETAs on the forums. Do you have only SoBR, no individual repositories?

[SteelContainer]

Hello,
We run cloud connect and normally send the clients config backup to the cloud but we are moving to sobr which doesn't allow us to do this anymore. So we still need a way to get the config offsite.
That was the simplest option in the past.
Thanks

[Shestakov]

I see. Unfortunately you need simple repository for configuration backup.
We will count your feedback as +1 feature request to conf. backup to SoBR.
Thanks!

[djenningsNI]

Add me to that count, I would like this option as well

[veremin]

Your voice has been counted. Thank you for the feedback!

[tfeerst]

Add me as well. We have a new setup and followed the recommendation of using SOBR then was disappointed to find we couldn't write the VBR configuration to these type of repositories. This would be way easier to only have to provide a single SOBR repository per tenant.

Current working solution is to write the VBR backup config to a hidden share of a protected machine that has a backup copy job running offiste.

[nitramd]

+1 for this feature request.

[tfeerst]

+1 for this request. I've tried a work around by adding another non-sobr repository but then service provider console backup policy jobs will randomly pick the non SOBR repository to place a backup job.

Cloud Repository
Cloud repository will be selected automatically from the list of available repositories.

[brunom]

+1

[JamieRidgeway]

+1

[Gostev]

@veremin let's make sure it is logged for v12.

[veremin]

Just placed a requirement for v12.

[bytewiseits]

+1 for config backup to SOBR.
Could I maybe add to the request though and have the possibility for VBR to backup the config to multiple locations (eg to Backup repository onsite, plus a SOBR in cloud connect). Can share the same frequency/retention just multiple separate copies/locations.

[AlexHeylin]

+100 for config backup to SP SOBR being allowed. I cannot see a single good reason for this to continue to be blocked. Right now for some tenants this means they don't have any useful config backup because the only place they ARE able to back up to is the repo on the VBR server. If VBR server dies they lose the config and the backup of it. Preventing tenants backing up their config offsite doesn't seem like what this block was supposed to achieve. I'd suggest that this is potentially a policy an SP would want Veeam to apply so that all tenant VBR could be made to back up their config to SP SOBR - which is the exact opposite of the current situation.

+10 for allowing config backup to any local-disk-only-SOBR, possibly with a warning. OK, so you might need to go and find the backup file yourself if it all dies. That's still a lot better than having no config backup at all because VBR blocks you from backing up to SOBR. Let's face it, no-one running VBR at any scale is ever going to create a non-SOBR every again as a main backup target. They're only created to work around artificial limitations placed in VBR, many of which were well intended but are now actively unhelpful. I suggest SOBR is the default repo type, and all of VBR is made to work with that. It doesn't seem a particularly big ask.

Perhaps config backups could be made special in some way that a copy is always retained on the performance tier (or at least, they're always held on local disk and never only in the cloud). That seems to address the genuine cases of needing the backup to access the repo which contains the backup.

[mikeely]

I look forward to this feature. Right now I'm having to use rclone to push the config backups to object storage and run an ungainly perl script (yay mojolicious though) to manage file retention by hand. Being able to send these to the SOBR would be ever so much better.

Edit: if anyone wants their own copy of this ungainly perl script until v12 comes out, you can find it here:
https://github.com/taupehat/scratch/blo ... -expire.pl

[FrancWest]

I recently opened a topic for this also, missed this one completely. Perhaps because it’s quite old…

See post405978.html#p405978

[TitaniumCoder477]

+1 feature request

I too ran into this today. However, it was further complicated by the fact the local repo was also SOBR!

If you encrypt the configuration file with a high entropy password, then this workaround could be considered:
1. Add one of your protected assets into Veeam as a server
2. Add a volume as a repo, maybe called "ConfigBackupRepoOnly"
(if you change the mount server for this repo, then you can avoid unneeded service pushing to asset)
3. Point your encrypted config backup to this repo

Your regular backup job will scoop it up. Your offsite job will send it offsite. The downside, obviously, is that it will be cumbersome to get at the backup config if you lose your backup server. You would have to at least import the backup file, restore just the config, and then restore the config etc.

[AlexHeylin]

Hi Jim,

Just to note that what you said about needing the config to access the SOBR is not true for VSCP SOBRs presented to tenants. All a tenant needs is their authentication info, and they could download the config for their system. All the SP SOBR SQL is held on the SP server, not the tenant isn't it?

Yes, in theory SP could also have a non SOBR repo, and present that to each tenant as well as the SOBR repo - but that adds complexity and work for no real reason.

In "on-prem" SOBR setups, it's not hard to find the file on disk (outside Veeam) and pull it across to the VBR server for recovery if needed. We get why you can't automatically find the config backup file in the SOBR - though actually, you can't do that in any repo. The repo has to be recreated in VBR in order for VBR to find the config backup file in it - so in this respect, is SOBR really that different? I personally would go find the file manually, rather than recreate repos etc in VBR when I'm about to restore the correct config anyway. Yes - you've potentially got more more extents to search manually with SOBR, but that's a small price IMO.

[jim.lowry]

@AlexHeylin that is an excellent point. This is true in regards to the scenario you described with VBR at a tenant site targeting a service provider's dedicated VCC SOBR repos. In the scenario with tenant's not using a VCC target, then the config backup would need to target a traditional repo attached to the tenant's VBR server. It would also apply to the VCC config backup file - that cannot target a local SOBR on the VCC server itself.

Again - excellent point and clarification - thank you for sharing it!

[jim.lowry]

My apologies everyone, I had some technical difficulties earlier this week that accidentally deleted my post from January 23rd, 2022. I'm re-posting it again now and will also copy the two posts that refer to it below. That way, it can be read within context of the original timeline.


------------------------------------- Start of Original Post From January 23rd, 2022 ------------------------------------------
I just had a customer ask me about this post and thought I'd add some color here. Hopefully we see this change in v12 as requested, but here's how it works right now.

The reason why config backup jobs cannot target SOBR repos is because of how SOBR works. In order to access/track extents and data residing within them, SOBR creates entries in a SQL database to keep track of the information (among other things). The config file backs up those entries so we can map SOBR extents and backup/replica data in the event of losing the VBR/VCC server. Without a config file, SOBR and its extents can’t be accessed. The question becomes if I need a config file to restore SOBR information, and I lose the VBR server, how do I bring SOBR online, grab the config file, and then restore access to SOBR? That’s why we can’t target SOBR and only traditional repos for a config backup job.


That being said, the workaround mentioned seems overly complex. It would work, but to your point it’s awfully complicated and not very efficient. So what do we recommend? Attach anything you want as a traditional repo and target that. It will run offsite as often as you tell it to via schedule or manually running the job. I find that using a file share server is the easiest and most resilient – especially if you are using something like OneDrive or Dropbox. There is no requirement for the target repo to be local to the VBR/VCC server. I also see customers use a removable USB drive on a server and target that. Then they can recover from the USB drive within the data center or keep it on your keychain. I recommend doing both, the size of the files are pretty small. I like the fileshare approach because it’s offsite and on different storage that is globally accessible quickly (3-2-1 rule should apply to config backups too). The USB keychain is nice because you have it right there physically with you if the internet isn’t available for some reason.


Config Backup Docs:

• Backup and Restore: https://helpcenter.veeam.com/docs/backu ... ml?ver=110

• Create/Schedule: https://helpcenter.veeam.com/docs/backu ... ml?ver=110

• Manually: https://helpcenter.veeam.com/docs/back ... l?ver=110

• BP Guide: https://bp.veeam.com/vbr/3_Build_struct ... ion-backup
  • The config backup section is brief, but the note about encrypting it is a good reminder.
  ------------------------------------- End of Original Post From January 23rd, 2022 ------------------------------------------
  
  ------------------------------------- Start of Posts That Are Responses to My Original Post From January 23rd, 2022 ------------------------------------------
  by jim.lowry » Tue Jan 25, 2022 7:57 am
  @AlexHeylin that is an excellent point. This is true in regards to the scenario you described with VBR at a tenant site targeting a service provider's dedicated VCC SOBR repos. In the scenario with tenant's not using a VCC target, then the config backup would need to target a traditional repo attached to the tenant's VBR server. It would also apply to the VCC config backup file - that cannot target a local SOBR on the VCC server itself.
  
  Again - excellent point and clarification - thank you for sharing it!
  Re: Config Backup to SoBR
  
  by AlexHeylin » Mon Jan 24, 2022 3:11 pm
  Hi Jim,
  
  Just to note that what you said about needing the config to access the SOBR is not true for VSCP SOBRs presented to tenants. All a tenant needs is their authentication info, and they could download the config for their system. All the SP SOBR SQL is held on the SP server, not the tenant isn't it?
  
  Yes, in theory SP could also have a non SOBR repo, and present that to each tenant as well as the SOBR repo - but that adds complexity and work for no real reason.
  
  In "on-prem" SOBR setups, it's not hard to find the file on disk (outside Veeam) and pull it across to the VBR server for recovery if needed. We get why you can't automatically find the config backup file in the SOBR - though actually, you can't do that in any repo. The repo has to be recreated in VBR in order for VBR to find the config backup file in it - so in this respect, is SOBR really that different? I personally would go find the file manually, rather than recreate repos etc in VBR when I'm about to restore the correct config anyway. Yes - you've potentially got more more extents to search manually with SOBR, but that's a small price IMO.
  ------------------------------------- End of Posts That Are Responses to My Original Post From January 23rd, 2022 ------------------------------------------

[AlexHeylin]

Hi,

I just want to follow up and see if "Allow tenant config backup to SP SOBR via CC" is an open / accepted enhancement request, or if I should specifically open a new thread for it?

I've hit another production case where the tenant has nowhere (useful) they can back the config up to, so we'll have to provision a small non-SOBR SP CC repo for their config backup because currently they're blocked from uploading it to the main SP CC SOBR repo.

Thanks

Alex

[jim.lowry]

I believe this is planned for VBR v12's release. If you would like to, you can install the VBR v12 beta2 code and test the functionality. I think it is part of the beta2 version of code, which is the current beta we're testing. I haven't tested that particular function, yet. I'll have to go poke around later this week. If you'd like to do the beta testing yourself, feel free to either PM me here or ping your local SE/SA directly. They'll have the secret squirrel beta access details.

[AlexHeylin]

Thanks Jim. I can't easily test this, so we'll wait to see it in release. I just wanted to make sure this had been picked up, and it has so thanks very much.
Alex

[jim.lowry]

@AlexHeylin I haven't been able to test the config backup to SOBR yet. However, I did read this morning while researching a related topic that config backup files will support going direct to object storage. That opens up a few other options for an offsite target of the config backup job. I thought you'd like to hear that.

[AlexHeylin]

Thanks Jim - it does, but as 95% of our clients access object storage via our SP SOBR repos, that's what we really need.

[jim.lowry]

I was able to determine in the just released VBR v12 Beta 3, that the config backup job cannot target a SOBR hosted by VBR or VCC. I'll update here with any information I find regarding this feature request.

I was able to confirm that config backup jobs can target object storage directly, which also supports S3 object level immutability (and eventually BLOB object immutability when it's officially supported). That can be verified with the v12 Beta 3 that was released this week. If you want to get a copy of v12 Beta 3, reach out to your local Veeam SE/SA and they can assist with that.

[bytewiseits]

Was this not logged as a requirement for V12 back in Nov 2020?
Looks like I wrongly assumed that it meant that it would be part of V12.

For us as an MSP, we backup our clients to a SOBR via VCC so would want to be able to put config backups there as well.
Note: we would want to have multiple Config backups - one onsite with the local backups, and one in VCC protected via the recycle bin as well. Same retention etc, just two copies/locations.

[veremin]

It was originally scheduled for version 12, but since this has been rather a long release cycle, some features changed their priority, and some got replaced with more demanding functionality added to the product build.

The same happened with the configuration backup to the Scale-Out Backup Repository requirement: it didn’t make it into v12 but will be delivered as a part of v12a.

Thanks!

[ndb8]

Thanks for the update, do we know when V12a might be released?