A couple of weeks back at Cloud Field Day one of the questions asked by the delegates was would the conversion process for the Direct Restore to AWS be faster if we stored the data within AWS as part of the backup process, for example if we were to have our on-premises operational restore window local to the production data but have a backup copy job sending a retention period to a completely separate Veeam Backup & Replication server and repository that is located within AWS.
I wanted to check and compare the speed and performance of this but also if we did see a dramatic increase in speed then at what cost does this come at.
As you can see from the diagram above, we have our production environment on the left and this is the control layer for the operational backups for our production workloads. We are then for the purposes of the test going to backup copy those backups to a secondary backup repository to a machine running in AWS. We then have a complete stand-alone system running within AWS that has Veeam Community Edition installed.
This Veeam Backup & Replication server within AWS is a Windows 2016 machine with the following specifications.
Availability Zone = us-east-2
On this machine we then installed Veeam backup & Replication – Community Edition, the functionality of cloud mobility is completely available within the free community edition.
The installation doesn’t take too long.
As you can see in the below image, we have a full backup file. this is located within the repository in AWS. Next up we need to import this to our AWS Veeam Backup & Replication server.
It’s really simple to import any Veeam backup first up open up the Veeam Backup & Replication console and connect to the Veeam Backup & Replication server, if using the console on the server then you can choose “localhost”
On the top ribbon, select import backup.
Depending on where that backup file is located you will need to select this from the drop down, if this is not on an already managed Veeam server (i.e separate to the the Veeam backup & replication server, you will need to add this)
We can choose different Veeam files I changed the file type to VBK so I could see the full backup file in the directory.
If the backup file also contains guest file system index, then you can check the box to import this also.
Next you will see the progress, this should not take long.
We are now in a position where we can see the contents of the backup, and from here we can begin our tests.
For us to test the direct restore to AWS functionality then we first need to add our AWS Cloud Credentials.
We can choose to add our Amazon AWS Access Key from the selection.
From your Amazon account you will need to provide your Access Key and Secret Key these are super super important not to share externally. These need to be super secure.
Notice how I am not going to show you my secret key.
You will then see your newly added cloud credentials.
Ok so at this stage we can right click on the machine we wish to directly restore to AWS.
The approach we take here is a very easy to use wizard, we choose our AWS Cloud Credentials from the drop down. Choose the Region and data center region you wish to restore the machine into.
Next up we need to choose the name we wish to use for the restored machine, but also we can add specific AWS tags.
I am going to rename mine to differentiate later on.
We then need to define the AWS Instance type we wish to use, you will need to make sure that the system you are sending there is supported by AWS for the OS.
Next, we choose the Amazon VPC and Security Group we wish to use.
We can choose if we would like to use a Helper Proxy Appliance.
Finally, we are able to give a reason for the restore.
Summary of the process and outcome.
This is the simple and easy to use steps you would take to get any direct restore to AWS.
Let’s get back to the test now, we want to know if by having this machine backup located within AWS would this make the conversion faster than having this on premises. This was the question asked during Cloud Field Day.
First of all, let’s take a look at the time it takes for the same machine from on-premises, the test is from our Columbus DC which also happens to be an AWS DC as well, I will reflect and take this into account later on.
This is the screen grab for the process that took place from on premises to AWS us-east-2 upload of data looks to have taken the exact same amount of time so the proof will be in the importing of the VM and if that is faster.
The on-premises system took 14:29 to import and 15:34 for the whole process to complete.
The connectivity for my “on-premises” location is as follows.
Now we want to run the same test using the imported backup file that we showed previously. As you can see the combined total took 12:39 and the conversion took 11:33 minutes.
The machine we are restoring is 1.1GB you can see the upload speed was the same regardless of the location of the backup, it’s the conversion that is slightly improved.
We also ran a test from our lab to us east 1 (North Virginia) and as you can see this was different again in terms of the import process.
I then wanted to test outside of our lab and very helpfully Jorge was able to run a test from his home lab, as you can expect his connectivity is not the same as an enterprise lab or data centre.
Jorge took the same machine, imported it to his Veeam Backup & Replication server within his home lab with a much slower upload speed than we have used previously but you can see that the import process and here we are importing to London and its quicker still. But the import process here shows it to be faster still.
I will continue gathering data points around this but the one clear statistic at the moment is it really doesn’t make any difference really on a small workload by having the backup stored within AWS already, now you consider a larger dataset and that import process time saving could be considerable but you have to really consider the costs behind storing those backups in AWS. And is it worth it.