VEEAM replica to AWS or Azure and then spin up

[jmcguigan]

Hi

I am looking at modifying our existing disaster recovery setup which currently replicates VMWare vSphere VMs to physical hardware in one of our other sites. The server and SAN are old and running out of space so am looking at more flexible options, but have a few questions.

If I send the replicas to Azure or AWS will I be able to spin them up for testing or if we do have a disaster. And if so, what do I need in place on either platform to do this. I have downloaded various AWS VMs (Storage Gateway etc) but sadly don't have enough spare space to fully build them on my infrastructure.

I'm agnostic about Azure or AWS, although AWS seems cheaper especially in running VMs.

Thanks in advance.

[veremin]

What exactly do you mean by replicas? Fully blown stand-by copy of your production VMs that you can fail over to in matter of minutes (replication job)? Or just additional copy of your backup data (backup copy job)?

Only the latter case is currently supported - you can copy your VM backups to backup repository deployed in Azure or AWS and then restore those VMs to Azure (feature already available) or AWS (feature will be available in Update 4).

Thanks!

[wishr]

Hi John,

Welcome to Veeam Community Forums and thanks for posting.

You have several options here:
1. Use Cloud Connect through the available service providers - this is the best option for replicating your workloads to a cloud.
2. Establish a VPN to a Cloud (AWS/Azure/VMware Cloud), create a Repository here, and instantiate your VMs from Backups when necessary through Restore to Azure feature (applicable to Azure). Replication won't be possible in that case, but this might be what you are looking for. You can also protect your cloud VMs with Veeam Agents as an additional measure.

There are some existing threads on our forums that you might want to have a look over, for example, this one and that one.

Please let me know if you have any additional questions. Thanks.

[jmcguigan]

Hi

I'm looking for production replicas that I can fail over to. I've already done some experiments with Azure File Share to create extra backup copies of my machines and that was a dawdle to setup, once I clear some space I will attempt the same thing with AWS.

If I'm reading v.Eremin correctly I can create a repository in Azure (already done), dump my VMs there (already done), and then migrate them to a working VM in Azure? What extra licensing/product from VEEAM would I need for that?

[wishr]

Hi John,

Restore to Azure that is built in Veeam B&R 9.5 is what you require for that.

BR,
Fedor

[veremin]

I'm looking for production replicas that I can fail over to

Then, as mentioned, it's currently not possible.

What extra licensing/product from VEEAM would I need for that?

No additional license is needed, you can restore backups to Azure even with Free edition. However, most likely you will need to solve network connectivity issues, using either native Azure VPN service or Veeam PN.

Thanks!

[jmcguigan]

Cheers.

I'm getting close but struggling to see any storage accounts using the Classic setup.

[wishr]

Hi John,

Could you please clarify what did you mean saying that? Appreciate any advanced details on what has been already done and what step is causing difficulties.

Thank you.

[veremin]

I'm getting close but struggling to see any storage accounts using the Classic setup.

Are you probably talking about Azure Classic deployment model? If so, can you elaborate on why you want to stick to this deployment model? Azure Resource Manager model is the recommended one.

While classic resources still exist and are supported, they can only be created in some (specific) locations.

Thanks!

[jmcguigan]

Hi

If I try to use ARM I get the password issue as mentioned here -> veeam-tools-for-microsoft-azure-f36/vbr ... 49664.html

So I've been plodding along with Classic as a proof of concept. I didn't realise that some locations wouldn't work, I've got my storage accounts in the Australia East/Southeast zones.

[veremin]

The workaround has been provided in the adjacent thread - just downgrade your PowerShell to 4.0 or similar. Otherwise, wait for Update 4 that should have this issue resolved. Thanks!

[jmcguigan]

Ah, thanks for that, I must have missed the downgrade suggestion but I will give that a whirl.

[jmcguigan]

Worked a treat, thanks for that.

I can now get on with my experimenting.

[veremin]

Good to hear that you're up and running now. As mentioned, the upcoming update will bring the updated PowerShell version with it, so the described behaviour should be an issue any longer. Thanks!