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:
And as we feared, the restore job was interrupted and failed after exactly 24 hours. There are 2 ways to work around this issue:
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
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.