Recovering from a disaster a Azure Blob storage

[IanJ]

Hi All,

We are using Azure blob storage for retention of GFS archive backups.

Playing through some scenarios we realised we need a procedure on what to do if you lose your Veeam servers and hence your database and vbm files.

With a backup that is still on a disk you can just import it, however for a backup store in Azure this doesn't appear to be an option.

I have tested this with some dummy backup data and it looks like your backups stored in Azure blob storage are "lost" (they are still in Azure, but there doesn't appear to be a way to get Veeam to recognise them) in this scenario.

I haven't been able to find any information on this scenario so I am wondering if there is a process to get these backups back.

[Mike Resseler]

Hi Ian,

All of the data is stored on Azure also. So even with a total loss of the on-premises datacenter, you still would be able to restore the data from Azure.

A few things come to mind this morning with my coffee
* Create a new VBR installation and add a new SOBR repository and connect the existing capacity tier again. That should get all the necessary information
* Simply deploy a free version of VBR and use direct restore to Azure

What things did you already tested and how?

Thanks
Mike

[HannesK]

just to add: with community (former free) edition you need to add the scale out repository & capacity tier with powershell as it is not available in the UI (community is "standard edition" which does not support scale out repository per default)

[IanJ]

I have tried this: * Create a new VBR installation and add a new SOBR repository and connect the existing capacity tier again

However no backups have appeared and the SOBR says that 0 space is being used. First rescan of the Azure Blob storage took about an hour and I can see on the Azure end there were transactions against it.

Will give it another crack, might have missed a step when trying it out.

[veremin]

If you have

- added the exact same object storage repository to a backup console
- added it as capacity extent to Scale-Out Backup repository
- re-scanned SOBR

and still can see no backups previously offloaded to capacity tier, then, reach our support team for further investigation, as the described behaviour doesn't look expected.

Thanks!

[anthonyspiteri79]

Hey there ...just to add to Vladimir's comment, I recently demoed this last week live at Cloud Field Day (though used Amazon S3) and I have done this process a number of times... works a charm.

Here is a little more info on the process and a video link of the demo: https://anthonyspiteri.net/disaster-rec ... loud-tier/

[dariusz.tyka]

I have similar situation here but with Amazon S3 storage. Support case number: 03487891.
I was testing capacity tier functionality and after some data was offloaded to object storage I simply deleted all content from performance tier (only one test job was targeted to it). Later on I made a rescan of SOBR but unfortunately those offloaded backups did not appear in Veeam console.
From support I got below info:
"I have discussed the issue with RnD team and the behavior is considered as a bug and will be resolved in a future release of the product."
So it looks like it is sitll not working as expected in some situations.

[HannesK]

Hello,
@dariusz.tyka: I was aware that there is an issue for your situation (I had the same in my lab ) . The workaround was to also remove the backups from configuration. After removing backups from configuration, the rescan worked.



But this should not be the case here, because he mentioned that he has a new setup.

Best regards,
Hannes

[dariusz.tyka]

Hi @HannesK,

I was instructed to remove backups from configuration but unfortunately it didn't change anything in my case. Still nothing in 'Disk-imported' on Veeam console.

[veremin]

Have you re-scanned SOBR, once backups were removed from configuration? Thanks!

[dariusz.tyka]

Yes, sure. Several times.

[veremin]

Hmm, looks unexpected. We will investigate your case internally and see what's the root cause of the behaviour experienced. Thanks!

[arti73]

Hi, we're working on similar scenario to execute a direct restore to Azure from MS Blob Storage. We're trying to estiamte how much space we need to provision for the "capacity tier" in the new SOBR repository to be part of the MV in Azure where we're going to install Veeam B&R. The size of the capacity tier should be the sum of all full backups of the VMs that we want to restore?

thanks in advance

Arty

[Gostev]

Hello, I'm not sure I understand the question. Capacity Tier uses object storage, which in case of public cloud has effectively no space limit. So, capacity tier size is not something you need to "provision"?

[arti73]

HI Gostev, sorry for the misunderstanding.. I mean "performance tier". In other words when you perform a SOBR Download Jobs the amount of space required in the performance tier to perform a direct restore to azure must be the sum of all full backups in the capacity tier?, I'm guessing the data is first moved from capacity to performance and that's the source when you execute a direct restore to AZ

[Gostev]

Ah, got it.

When importing backups from object storage, we only download metadata to the Performance Tier, and re-create backup file stubs using this metadata. I don't remember the exact figures on the amount of metadata, but it should be less than 1% of your backups size for sure.

And once the backups are imported, you can start restoring directly from the object storage. Unlike with other vendors, there's no requirement to download entire backups to the Performance Tier first. Besides, doing so would not make any sense in your particular restore scenario anyway (direct restore from blob storage to IaaS), as both source and target are located in the same physical Microsoft Azure data center.

[arti73]

You guys really put a lot of thought on this, it rocks how it works ! Thanks for continuous effort to support the commnuity

[Gostev]

Wow, I think you just came up with our new motto

[arti73]

Looking forward to get a Veeam t-shirt with the new motto