In this post I am exploring connecting Veeam to an Azure based Linux Repository for the use of doing a Backup copy, specically a Log Backup copy using the immediate copy mode launched with v10.
The reason for this is because Veeam Cloud Tier does not allow the copy of VLB files aka Log Backup files.
The above diagram shows the overview of my lab environment.
First I have a lab subnet which holds part of my lab VMs, the networks are routed using a PfSense Router which in turn connects to my home Router then to the internet. Nothing to crazy there.
The first thing I had to do was to create a VM in Azure to work as my remote repostory, I opted for a B2s VM running Ubuntu 18.04 with a S6 64GB HDD managed volume attached for the copy data.
In additon to this I used VeeamPN which is free software from Veeam that allows you to create a VPN to your network. It is available from:
https://azuremarketplace.microsoft.com/en-us/marketplace/apps/veeam.veeampn
Of course the VM running VeeamPN does have a cost attached, between the two VMs the total cost according to the Azure calculator was $84. Most of that was the compute, upping the capacity didn’t actually cost a lot more.
The installation process is pretty simple, the online guide provides all the information you need to set it up.
https://www.veeam.com/veeam_pn_2_1_user_guide_pg.pdf
You also need to download the VeeamPN hub OVA from the Veeam website, again this is free. You don’t actually need this if you are planning to connect a single host to VeeamPN as you can install and use OpenVPN; however, as the Backup Server also needs to communicate to the remote repo, it makes sense to install the simple-to-use hub VM.
The one slightly more complicated piece was getting the PfSense set up to use the Gateway. What I did with this was to download the configuration XML from VeeamPN and do the following.
- Add the cert in the CA under “System/Certification/CAs”, you’ll need to change the method to “Import an existing Certification Authority”
- Add the certificates under “System/Certification/Certicates”, just a copy/paste of the Private and Public keys.
- Create a new gateway under “System/Routing/Gateways”, I assigned this to the IP address of the VeeamPN Hub.
- Creat a static route with the destination as the Azure subnet e.g. 10.1.2.0/24 and assign the new VeeamPN Gateway.
Once all that is done you should be able to ping your Azure VM assuming you don’t have any firewall rules that might block access.
The Azure based VM required me to format the sdc disk with XFS, my friend Jorge De La Cruz has a great post on this subject.
The rest of the process is the same as adding a repository locally through the Veeam GUI; however, remember that you will need to create an SSH key on the repository and VBR servers to be able to connect to the Azure VMs. Those public keys will then need to be copied to the Azure VM’s know_hosts file.
I personally did this manually by doing the following
sudo nano ~/.ssh/known_hostsThen doing a copy/paste of the public keys then saving off the file.
SQL Log Cloud Copies
This section still needs research to confirm certain aspects.
You are able to do a backup copy of the absolute minimum to the copy which is two restore points. However, you are able to set the log shipping to far longer.
What this means is that you can dramatically decrease the amount of data held in the cloud for the VM portion of the backup while having an extended log backup. Cloud Tier is completely seperate from Backup Copy so you could have longer retention, using tiering, as well as another copy in the cloud using that option.
The potential process in case of emergency then would be to grab the backup flies from the cloud based repo. In the case of Azure this could be achived using VeeamSCP or any other means of copying over the network.
https://www.veeam.com/fastscp-azure-vm.html
https://www.veeam.com/veeam_fastscp_azure_1_0_user_guide_pg.pdf
Why is this a good thing? Well you could of course do a straight copy of the logs using the Azure/AWS CLI to copy a folder to the a bucket which is a low-cost option. The problem with this is that it is unsupported by Veeam, so if you have any issues then it’s on you. Not say it won’t work, and it would be cheaper, but I couldn’t recommend it. Doing it this way keeps it under support.
This of course is another option for the copying of logs to the cloud and is supported by Veeam. However, as it isn’t part of the main console so requires seperate management, it isn’t my recommended option.
Assuming you also downloaded the Main VM backups from copies that you sent to Azure via Capacity Tier, the VLB files can be placed in the same directory as the VBK & VIB files and if they are of a matching timescale, the logs will ‘reconnect’ allowing granular restore points.