about Windows, System Center, Azure etc..

I recently had to help a customer with a restore from Azure. They were hit by ransomware and got their file server encrypted. Not an issue, they had Azure Backup configured by doing a file backup of the full VM (vhdx files), so it could be restored. Then came this message:

Recovery volume is available till 31-01-2019 14:34:42. Mount time is extended to a maximum of 24 hours in case of an ongoing file-copy.

And as we feared, the restore job was interrupted and failed after exactly 24 hours. There are 2 ways to work around this issue:

Registry key

First workaround is adding a registry key to the server where you are restoring the file, with the following information:Path: HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows Azure Backup\\Config\\CloudBackupProvider Name: RecoveryJobTimeOut Value: Amount of hours you need for your recovery job to run, 36 for example

This is the recommended workaround. Please note that the dialog box will still tell you that you have a 24 hours limit, but this is not the case! It’s just a static warning in the client.

Pause file copy

Another option is to pause the file copy. It’s just a simple file copy from a source to a destination. If you pause it before the 24 hour limit and dismount of recovery volume, you can initiate a new restore and mount of the volume, and continue the file copy.

I don’t recommend doing this, since it’s easy to mess up and then you would have to start over.

The best solution

So these are just workarounds. The best solution is to build a backup solution that works as needed, and from my experience >24 hours of restore time is rarely accepted. You can do estimates of how long recovery will take, since we know some of the numbers:

Bandwidth – how much bandwidth do you have? Azure is limited to ~60 Mbps when restoring, so even you have more bandwidth it won’t help.

Restore size – how much data do you need to restore?

In this situation we had about 620 GB to restore, and 100 Mbps internet. Due to the 60 Mbps limitation the restore time was around 25 hours, so we weren’t that far from the limit. There were some lessons learned for the customer in this case, and we’re doing a reconfiguration of their backup now. The file server is no longer backed up on the VM level, but rather file level. This is much better for a server like this, where normally they would only need to restore a few files.

I just had to migrate a Storage Account from ASM to ARM, and ran into some issues while doing this. This time the error was a bit difficult to figure out, because the Validate step completed successfully, but the Prepare step failed with “internal server error”.

After some mails back and forth with Azure Support they engaged with engineering who could tell that one of our Azure Policies blocked the migration. Specifically, we had assigned a policy that blocks creation of new storage accounts, if they they allow HTTP access to blobs. The policy is built-in and named “Ensure https traffic only for storage account”.

After disabling the policy, I was able to migrate the Storage Account, enable HTTPS only traffic, and assign the policy again.