Veeam Cloud Edition required for restore to AWS?

[cparker4486]

Hello,

Just found this great video http://www.youtube.com/watch?v=KzziVR2mg_Y and I wondered if Veeam Cloud Edition is actually required to do this? It seems that it's not as long as I can get files into and out of an S3 bucket (from my AWS staging machine, as shown in the video).

Another question, regarding licensing of B&R, I assume that I will need an additional license of B&R if I am to install it on the AWS staging server. Is this correct?

[Gostev]

Hi Chris, sure - you can other ways to deliver files there.

You don't need any extra Veeam license, remember we only charge for protected sockets. You can install as many Veeam B&R components as you like, anywhere you like, free of charge.

Thanks.

[cparker4486]

You know I knew about the per socket licensing but I thought it would be too good to be true that I could install the full B&R without charge on AWS.

[Gostev]

I thought it would be too good to be true

Welcome to Veeam

[Dave-Departed]

So did anyone ever actually discover where the guy who made the video put his notes?? Because of unimpressive Veeam licencing restrictions, I'm now having to consider doing this, but without using Cloud Edition, and basically by using AWS VPC and having a Veeam server EC2 instance connected to our head office via VPN.

I'd be interested to see how it can be done by scripting (something which is not my strong point haha!)

[dellock6]

Dave,
I've taken a look at the video, cool solution indeed, but they key point there is the double conversion of the VM files:
Veeam VBK backup -> VM vmdk files -> Convert to OVF -> import OVF into Amazon
You can do this even without the cloud edition, as you said by having a Veeam repository (and hopefully also a wan accelerator) into a windows machine into AWS. If you also install Veeam console in that VM, when you need you can simply import VBK files from S3 and start from there, as in the video.

About the scripting, I've seen little to no scripts in the video, and instead many many manual steps. Seems like the author said "it could be scripted, but I didn't".

Luca.

[tsightler]

For now, restoring into AWS from a Veeam backup has a reasonable number of steps, but it's pretty much just extracting the VMX/VMDK from the Veeam backup and then running the import. As far as I know, there's no actual requirement for the OVF step as the EC2 import tools support importing VMDK directly, so it's basically extract the files, and run one command similar to this (ripped directly from Amazons online help):

Code: Select all

ec2-import-instance ./WinSvr8-2-32-disk1.vmdk  –f VMDK -t m1.small -a i386 -b myawsbucket -o AKIAIOSFODNN7EXAMPLE -w wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY -p Windows

If your backup files are stored somewhere that there's vSphere infrastructure available, it's probably easier to use Amazons VM Import Connector which is a small virtual machine that you can deploy in your vCenter infrastructure. You can then use Veeam instant restore and the GUI tool to import the VM into AWS.

Scripting this up would just be a matter of using Start-VBRRestoreVMFiles to extract the files and the above command to perform the import, assuming VMs with a single VMDK anyway. If you have additional VMDK files I think you need to loop through them and use ec2-import-volume then attach them to the instance. I guess the question is whether it is worth it since most of the use cases would be for restoring a relatively small number of systems and it's pretty easy to go through the handful of steps manually.

[Dave-Departed]

Thanks for the input, guys!

tsightler, thanks for the heads up on EC2 natively supporting VMDK format, that's a time-saver!

As for the AWS Import Connector, I've tried that on both vSphere 5.0 and 5.1 and it's never worked for me (apparently there's a known issue, Amazon doesn't support it on those versions, unless there's been a new version that I don't know about?).

Scipting-wise, I think I'll just forget about it for now, seeing as not having to convert to OVF would save us a fair bit of time.

I will report back on how I get this setup, as it's very interesting to me!

[Dave-Departed]

Ok, I've hit a snag...

So my Veeam VM in AWS is inside my VPC, and I have an EBS volume attached to it, which is configured as a VBR repository, and is where the .VBK files from the Backup Copy Job reside. I have another EBS volume which I've attached to my AWS Veeam VM, which acts as the staging area (so this is where I restore the extracted.VMDK files, etc, from the Veeam backup). And then I want to run the EC2 Import Instance command... But I don't have an S3 bucket to specify, because the .VMDK files reside on the EBS volume attached to my AWS Veeam VM!

Does anyone know if there's a way of specifying an EBS volume to read from INSTEAD of an S3 bucket, with the import instance tool, please??

Thanks

Dave

[tsightler]

It's been a while since I've done this, but from my memory the S3 bucket isn't used to read the data from, it's used only to store the manifest data for the import, i.e. it's a target. So you'll need to create yourself a bucket for the import to use and simply specify that. The import tool is going to read the local VMDK, upload a manifest to an S3 bucket and then use the metadata in that manifest to import the disk image into an EBS volume. At least, that's how I remember it. I do know for sure that you don't have to upload the VMDK itself to the S3 bucket as the import tool itself runs on the local machine and reads the local disk image from the provided path. I guess the tool might be chunking the file into S3 for conversion to EBS (I have no idea how the tool itself works), but once again, that means the bucket is just a target, you don't have to get the file there first.

[Dave-Departed]

Thanks for that, you were right!

However, when I'm trying to run the import instance command on the VMDK files restored from Veeam, I get the result:

ERROR: This does not appear to be a Stream Optimized VMDK. It contains invalid magic number 1766072355

Anyone got a clue what this means, and how I would stream optimize it, please (bearing in mind I've successfully processed a VMDK file direct from my vSphere infrastructure into EC2 just fine before)?

Thanks

Dave

[tsightler]

So that rings a bell and it looks like I was giving you some bad advice as I'm sure that's why, in the original video, Luke performed the conversion to OVF as that process would convert the VMDK from it's normal "Thin" or "Flat" type to a "Stream Optimized" type and it appears based on that error that the ec2-import utility only supports stream optimized VMDK images, so you probably will need that extra conversion step to OVF. I was confusing that procedure with a different procedure that I use locally.

[aeccles]

I had a similar goal a few months ago with Azure and wasn't able to find a way to do it without a similar extraction/conversion/import. I looked again last week and couldn't find anything that had changed to make it easier. I believe it would work, but the amount of time it would require was too much to meet my needs. My (very rough) estimation was that the process to get a 1TB of VMs would take a day or so get running. The most concerning part was that Azure deprioritizes transfers to the blob storage so what might take 30 minutes one day could take 2 hours the next.

I'm wondering if anyone has found a provider that can provide an easier method? The hang up seems to be either the requirement to convert the VM or the time it takes to copy the VM file to the bootable storage area. I know there are some Veeam VCPs that provide DR as a service but the vendors I spoke with were asking for a premium- understandably though due to the hardware dedication requirements on their end.

[Dave-Departed]

I echo aeccles' sentiment... After testing last week, and it taking hours and hours to convert a 20gb VMDK file, I'm hoping there's a quicker/easier way? Or whether Veeam and Amazon can get their heads together and figure something out for a later release, perhaps?

[dellock6]

I would say a quicker way is to rely on a provider based on VMware vCloud; even if you need to have some sort of access to the underlying vCenter (it can be done with some permissions on it), at least there is no convertion needed, and the job only requires to extract the vmdk from backup, and publish it on vCenter/vCloud.

But at this point I would search for the opposite, that is a CSP able to ingest your Veeam backups, and mount them in their own infrastructure when needed.

Luca.

[Dave-Departed]

Thanks Luca. So like someone who's a member of the Veeam Cloud Provider program, for instance?

[dellock6]

Indeed. There are no specifications or mandatory configurations about how to implement VBR at a Cloud Provider, so in uor shoes I would check with them how they are using VBR to offer their services. These forums are filled with good advices about how to do a proper off-site backup, and could be used as a starting reference for a CSP design.

(and no, I'm not going to suggest any of them, I'd like to be fair and equal with all)

Luca.