Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article provides step-by-step procedure to perform point-in-time recoveries in Azure Database for MySQL - Flexible Server using backups.
Prerequisites
To complete this how-to guide, you need:
- An Azure Database for MySQL flexible server instance.
Restore to the latest restore point
Follow these steps to restore your Azure Database for MySQL - Flexible Server instance using an earliest existing backup.
In the Azure portal, select your Azure Database for MySQL - Flexible Server instance that you want to restore the backup from.
Select Overview from the left panel.
From the overview page, select Restore.
The restore page appears with an option to choose between Latest restore point and Custom restore point.
Select Latest restore point.
Enter a new server name in the Restore to new server field.
Select OK.
A notification appears that the restore operation is initiated.
Restore to a fastest restore point
Follow these steps to restore your Azure Database for MySQL - Flexible Server instance using an existing full backup as the fastest restore point.
In the Azure portal, select your Azure Database for MySQL - Flexible Server instance that you want to restore the backup from.
Select Overview from the left panel.
From the overview page, select Restore.
View the restore page with an option to choose between Latest restore point, Custom restore point, and Fastest Restore Point.
Select Select fastest restore point (Restore using full backup).
Select the desired full backup from the Fastest Restore Point (UTC) dropdown list.
Enter a new server name in the Restore to new server field.
Select Review + Create.
After selecting Create, view a notification that the restore operation has been initiated.
Restore from a full backup through the Backup and Restore page
Follow these steps to restore your Azure Database for MySQL - Flexible Server instance using an existing full backup.
In the Azure portal, select your Azure Database for MySQL - Flexible Server instance that you want to restore the backup from.
Select Backup and Restore from the left panel.
View the Available Backups page with the option to restore from available full automated backups and on-demand backups taken for the server within the retention period.
Select the desired full backup from the list by selecting on corresponding Restore action.
View the Restore page with the Fastest Restore Point option selected by default and the desired full backup timestamp selected on the View Available backups page.
Enter a new server name in the Restore to new server field.
Select Review + Create.
After selecting Create, view a notification that the restore operation has been initiated.
Geo restores to latest restore point
In the Azure portal, select your Azure Database for MySQL - Flexible Server instance that you want to restore the backup from.
Select Overview from the left panel.
From the overview page, select Restore.
The restore page appears with an option to choose Geo-redundant restore. If you configured your server for geographically redundant backups, you can restore the server to the corresponding Azure paired region and enable the geo-redundant restore option. The geo-redundant restore option restores the server to the latest UTC Now timestamp. After you select Geo-redundant restore, you can't select the point-in-time restore options.
Enter a new server name in the Name field in the Server details section.
When the primary region is down, you can't create geo-redundant servers in the respective geo-paired region because storage can't be provisioned in the primary region. You must wait for the primary region to be up to provision geo-redundant servers in the geo-paired region. When the primary region is down, you can still geo-restore the source server to the geo-paired region by disabling the geo-redundancy option in the Compute + Storage Configure Server settings in the restore portal experience and restore as a locally redundant server to ensure business continuity.
Select Review + Create to review your selections.
A notification appears that the restore operation has been initiated. This operation might take a few minutes.
The new server created by geo restore has the same server admin sign-in name and password that was valid for the existing server at the time the restore was initiated. You can change the password from the new server's Overview page. Additionally, during a restore, you can configure Networking settings such as virtual network settings and firewall rules as described in the following section.
Use restore to move a server from Public access to Private access
Follow these steps to restore your Azure Database for MySQL - Flexible Server instance using an earliest existing backup.
In the Azure portal, select your Azure Database for MySQL - Flexible Server instance that you want to restore the backup from.
From the overview page, select Restore.
The Restore page appears with an option to choose between geo restore or point-in-time restore options.
Choose either Geo restore or a Point-in-time restore option.
Enter a new server name in the Restore to new server field.
Go to the Networking tab to configure networking settings.
In the Connectivity method section, select Private access (VNet Integration). In the Virtual Network section, you can either select an existing virtual network and Subnet that is delegated to Microsoft.DBforMySQL/flexibleServers or create a new one by selecting the create virtual network link.
Note
Only virtual networks and subnets in the same region and subscription appear in the dropdown list.
The chosen subnet is delegated to Microsoft.DBforMySQL/flexibleServers. It means that only Azure Database for MySQL - Flexible Server instances can use that subnet.Create a new or select an existing Private DNS Zone.
Note
Private DNS zone names must end with
mysql.database.azure.com
.
If you don't see the option to create a new private dns zone, enter the server name on the Basics tab.
After you deploy the Azure Database for MySQL - Flexible Server instance to a virtual network and subnet, you can't move it to Public access (allowed IP addresses).Select Review + create to review your Azure Database for MySQL - Flexible Server configuration.
Select Create to provision the server. Provisioning can take a few minutes.
A notification appears that the restore operation is initiated.
Autoscale IOPS for faster restore
You can enable autoscaling of IOPS for both the source and target servers during restore operations. You can only select this option if the source server doesn't already have autoscaling of IOPS enabled. Temporarily boosting IOPS helps speed up the restore process by meeting its increased performance demands. When provisioning is complete, you can disable autoscaling if it's no longer needed. In the restore workflow, you see a checkbox option labeled Fast Restore. Select this option to use autoscaling of IOPS for a faster and more reliable restore operation.
Perform post-restore tasks
After the restore completes, perform the following tasks to get your users and applications back up and running:
- If the new server replaces the original server, redirect clients and client applications to the new server.
- Make sure users can connect by setting up appropriate virtual network rules. These rules aren't copied from the original server.
- Make sure appropriate logins and database level permissions are in place.
- Configure alerts as appropriate for the newly restored server.
Common errors
Restore to same server name isn't supported. Use a different name when you start the restore process, otherwise restore operations fail.
Ensure server isn't in "Inaccessible" state during restore. Restore isn't successful for such servers.