Skip to main content

In my job as a system consultant specialised in Backup and Disaster Recovery (covered by Veeam products of course :blush: ) at a MSP, I’m also responsable for the Veeam Cloud Connect infrastructure and offering.

 

This article is regarding recovering data from Veeam Cloud Connect where I ran into a shortcoming…

 

We are offering BaaS using Veeam Cloud Connect. Most of those tenants are sending a copy job to our infrastructure so they are having an offsite copy and optional insider protection as an ‘airgapped’ copy : see more info on my post regarding the golden rule 3-2-1-1-0 3-2-1-1-0 Golden Backup Rule | Veeam Community Resource Hub.

We are optionally offering a yearly restore test of the backups we are having at our cloud connect repositories.

For this I have implemented a seperate Veeam Backup & Replication server that has access to the Veeam Cloud Connect Repositories.

We are using Azure implementing Direct Restore to Azure for those restore tests.

In this restore test we just restore the wanted VMs to Azure, verify if they are started perfectly and if we can logon and verify if the disks are visible, automatic services are started, … No real disaster recovery test is performed, so applications are not being tested in the offered restore test, just testing the viability.

A real disaster recovery test is always a separate customized project.

This procedure is functioning perfectly.

In a real disaster scenario, everything is ready to start this procedure, recovering the wanted VMs to Azure (at this moment to our own Azure tenant, but we can easily add the tenant of the customer in this case).

Only a few people (the VCC team) including myself are having access to the Veeam Cloud Connect infrastructure. The system engineers working exclusively for customers and are no member of the VCC team and are not having access to this infrastructure.

 

Now what challenge did I have today :wink: .

Apparently there was a project sold to a customer to perform a real disaster recovery test.

No problem so far…

The customer wanted the backups at Veeam Cloud Connect as a source for the disaster recovery test.

Still no problem…

Next to that a system engineer had to implement this without having access to the Veeam Cloud Connect infrastructure.

Not yet a problem…the VBR infrastructure of the tenant can be used having access to the Veeam Cloud Connect.

The VMs being restored had to be restored to Azure.

OK, it’s getting a challenge. I said to my colleague that this is possible, just create an Azure tenant for the customer with a subscription so this can be added to their Veeam console so direct restore to Azure can be used.

I also mentioned that this way direct restore to Azure is not possible in one way : it is not possible to restore directly to Azure (or AWS) from cloud connect backups, so first the backups needed to be downloaded first.

If this was not yet enough, the upload capacity of the customer their environment is very small.

Still no problem, I advised to implement Veeam Backup & Replication from the marketplace in Azure, add the service provider connection in this server so they can download the backups onto Azure and of course afterwards the direct restore will be much faster.

In a real disaster recovery scenario it would be obvious to implement it that way because the on-premises backup server would also not being available anymore.

OK now?

Nope, unfortunately.

Then my colleague asked me how to download the backup-files first.

Export? Damn, indeed that is not possible because if you export a backup it is always exporting this backup to the repository where the existing chain is resisted.

More info : Exporting Backups - User Guide for VMware vSphere (veeam.com)

Ok than, we will use the copy functionality, no problem.

Yeah right, all is disabled…

It seems that this is possible from Veeam Cloud Connect, but NOT if the service provider is using a SOBR

More info : Copying Backups from Cloud Repositories - Veeam Cloud Connect Guide

Now it is getting very hard to come with a solution.

Therefore I created a new VCC tenant referring to a simple repository at Veeam Cloud Connect and copied the chain of backup-files for this customer (I created a separate tenant because I did not want to impact the existing chain which is still used, it’s only a DR test, not a real DR scenario)

At the VBR server in Azure, created the new service provider connection to this new tenant and bingo : the system engineer can copy first the backup files to temporary storage in Azure and implementing direct restore to Azure afterwards.

 

Of course it was easier to give my colleague access to the VBR server used for restore tests, but that is not the best idea, if one may, two will ask, etc...

Also in a real disaster recovery scenario, the VCC team will restore directly from the VCC infrastructure to Azure as already mentioned.

 

But having this challenge I see some feature requests for Veeam :wink:

  • copy functionality possible from a VCC SOBR
  • export functionality to another location
  • direct restore to Azure possible from Veeam Cloud Connect backups

 

@Kseniya and @Rick Vanover : what is the best way to ask for feature requests being a Veeam Legend? 

Using like this, using a separate topic in the Veeam R&D forums, ..

 

And for other Veeam Legends and members of this community that are offering VCC : how do you perform that disaster recovery tests using VCC backups as a source?

 

thx

regards

Nico

 

 

 

I would think posting in the R&D forums would be the best place to put your suggestion.


Hi @Nico Losschaert - funny timing and great topic.

So…

For now, FR’s are to go into the Forums.

For later, Mrs. KZED and I are scheming an upgraded approach. @Kseniya ...


Thx for your feedback @Rick Vanover .


@Rick Vanover and @Kseniya : In the meantime I put a post on the R&D forum and already got the following answer to the recommended feature requests for the VCC infrastructure : :laughing:

 

Hello,
sounds like valid feature requests and we are working on some of them for V12 actually :-)

Best regards,
Hannes


@Nico Losschaert  that’s great to read!


Nice to see they took the suggestion Nico.


Comment