Skip to main content
  • EN

 

Ever had your backups fail? I sure have! But it’s all part of the fun & games of learning exactly how these systems work.

Recently I spun up another instance of Veeam Backup for Microsoft Azure, and as part of my security mindset, I configured some elements of hardening to my infrastructure. Well, I missed a setting that I’m going to share with you today.

 

Worker Job Completed with Error

 

So, I had Veeam Backup for Microsoft Azure working, my daily snapshot job was also running fine, but it was the daily backup that wasn’t working. Some of the key terms I could pick out from the logs were ‘Worker: <Resource Name> (IP Address:Port): job completed with error’, ‘Error: This request is not authorised to perform this operation’, ‘Status 403’, and ‘ErrorCode AuthorizationFailure’ were the error messages I was being greeted with.

 

Dissecting the Errors

 

The key hint here was the job task ‘Backing up <VM Name> to Backup Repository. Followed by the worker not being authorised.

Within Veeam Backup for Microsoft Azure, backups are stored on storage accounts, so I started here. I’d configured my storage account to only be accessible from my VNETs and from the public IP address of my Veeam Backup for Microsoft Azure virtual machine, so I was quite confident I’d done everything right, but this was where I was mistaken.

 

The Root Cause: Worker Permissions

 

Unfortunately, whilst I had set the relevant permissions, my worker VM needed to interact with this storage account, but it didn’t exist at runtime. When Veeam Backup for Microsoft Azure creates the worker VMs, it creates appropriate VNETs for them within their region, and because I’d configured my security permissions prior to the creation of the worker VM, I’d never included the worker VM’s VNET into my networking security rules for access to my storage account!

Once this rule was added, it worked!

 

Always enjoy reading these posts to gain some knowledge on other pieces of Veeam. 👍

Nice one @MicoolPaul :)

Great post! Pointed me directly to the solution I was looking for :)

Great post! Pointed me directly to the solution I was looking for :)

That is great to hear and nice to see the community helping as always.  😁

So if there’s anyone out there running into this error with close to 0 Azure experience like me, here is what you need to do.

  • In Azure, you previously created a storage account to use as repository, click on that.
  • Choose Networking (you can search the menu points on the left).
  • In the Virtual Networks section click Add virtual network.
  • On the newly opening page, click on the drop-down under Virtual Networks.
  • Here, you will see a list of all your networks, find the one which belongs to the resource group of your Veeam Azure appliance, if you created your appliance using Veeam Backup and Replication, it will start with veeam-.... Now, HERE will you see what is on the teeny-tiny screenshot in the article: a network with a name starting with VBA_VNET… This is what you’ll need to add.

  After this, the job will run fine.

Peace, m

So if there’s anyone out there running into this error with close to 0 Azure experience like me, here is what you need to do.

  • In Azure, you previously created a storage account to use as repository, click on that.
  • Choose Networking (you can search the menu points on the left).
  • In the Virtual Networks section click Add virtual network.
  • On the newly opening page, click on the drop-down under Virtual Networks.
  • Here, you will see a list of all your networks, find the one which belongs to the resource group of your Veeam Azure appliance, if you created your appliance using Veeam Backup and Replication, it will start with veeam-.... Now, HERE will you see what is on the teeny-tiny screenshot in the article: a network with a name starting with VBA_VNET… This is what you’ll need to add.

  After this, the job will run fine.

Peace, m

Thanks for posting this fix @madradena and hopefully it helps others.

Comment


Terms & Conditions