We accidentally deleted a production Azure Database for MySQL Flexible Server in Central India and tried to recover it using the documented dropped-server point-in-time restore API. The restore request is accepted, but provisioning fails with ResourceOperationFailure and ProvisionNotSupportedForRegion. We tested different destination names and restore points, verified the region and source resource ID, and confirmed that the subscription has enough quota. Attempting the restore in South India instead returned RestoreSourceServerNotExist, which may simply indicate that the backup is tied to the original Central India region. Has anyone encountered this error during a dropped-server restore, and was it ultimately caused by a Microsoft backend or regional capacity issue?
2 Answers
The restore request itself looks reasonable. The RestoreSourceServerNotExist response from South India likely means the recovery metadata is scoped to the original Central India region, rather than proving that the backup is gone. Confirm that the restore point is before the deletion time and that it is still within the configured retention period. Ask Microsoft to investigate through a quota or capacity support case, even though this is not necessarily a normal quota problem, because that route can reach the backend team that enables the restore.
This can happen when the region has insufficient capacity or when Microsoft has a backend provisioning or feature-flag problem. I have seen similar errors during capacity issues in other regions, where moving the workload elsewhere was the only temporary option.
Thanks for the detailed explanation. Our Azure partner opened a critical support case with Microsoft, and they were ultimately able to unblock the backend issue. We successfully restored the database.