Azure Database for MySQL Flexible Server Point-in-Time Restore (PITR) consistently fails before restored server is created (West US 2)

Moses Onilede 0 Reputation points
2026-07-31T14:55:02.81+00:00

Summary

I am encountering a repeatable failure when performing a Point-in-Time Restore (PITR) of an Azure Database for MySQL Flexible Server.

Every restore attempt fails before Azure creates the restored server.

The source server remains healthy and operational throughout the process.

This appears to be a provider-side restore failure rather than a database availability issue, but I would appreciate confirmation from Microsoft or anyone who has experienced similar behavior.


Environment

Service

Azure Database for MySQL Flexible Server

Region

West US 2

Subscription

Microsoft for Startups sponsored Azure subscription

Support Entitlement

Developer

Source Server

mysql-encycloamts-platform-stg-wus2


Expected behavior

Selecting a valid point within the configured backup retention period should create a new Azure Database for MySQL Flexible Server restored to the requested point in time.


Actual behavior

Every Point-in-Time Restore attempt:

  • starts normally,
  • progresses into the Azure-managed restore workflow,
  • fails before completion,
  • never creates the restored server.

The source server remains healthy and continues serving requests.


Current resource status

Source server:

  • Status: Ready
  • Public access: Disabled
  • Production workload unaffected

Restore target:

  • Never created

Temporary restore resources:

  • None

Investigation completed

I have already completed extensive troubleshooting.

Azure RBAC

Verified.

The account performing the restore is the Subscription Owner.

Authentication

Verified.

Authorization

Verified.

Microsoft.Support provider

Verified.

Provider:

Microsoft.Support

Status:

Registered

Azure Support REST API

I attempted to create a technical support request using the Azure Support REST API.

Authentication succeeded.

Authorization succeeded.

The request then failed entitlement validation with:

InvalidSupportPlan

Request ID:

fbf12741-f4a2-4d01-abbd-2ef712c96cb5

Azure Portal

I completed the Azure Help + Support workflow using:

Azure Database for MySQL Flexible Server

Backup, Restore and Business Continuity

Point-in-Time Restore

Azure completed automated diagnostics.

The workflow returned only general documentation regarding backup and restore concepts before directing me to Microsoft Q&A.

It did not provide a mechanism to create a technical support request.

Items already ruled out

The following do not appear to be responsible for the issue:

  • Azure RBAC
  • Authentication
  • Authorization
  • Subscription permissions
  • Microsoft.Support registration
  • Azure Portal malfunction
  • Incorrect support endpoint
  • Source server availability

Question

Has anyone encountered Point-in-Time Restore failing before the restored server is created while the source server remains healthy?

Could this indicate:

  • backend restore orchestration failure,
  • backup metadata corruption,
  • regional capacity issues,
  • storage snapshot problems,
  • or another provider-side condition?

If Microsoft engineers review this post, could you advise whether backend diagnostics are available to determine why the restore operation terminates before provisioning the restored server?

I can provide:

  • Activity Log entries
  • Restore operation IDs
  • Correlation IDs
  • ARM request IDs
  • Azure CLI commands
  • Exact timestamps
  • Portal screenshots
  • Any additional diagnostics that would assist.

Thank you for your assistance.

Azure Database for MariaDB

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.