We’re pleased to announce that Azure Database for MySQL - Flexible Server now offers added flexibility in choosing geo-redundant backup storage to provide higher data resiliency. Enabling geo-redundancy empowers you to recover from a geographic disaster or regional failure if you can’t access your server in the primary region. With this feature enabled, you can perform geo-restore and deploy a new server to the geo-paired Azure region using the original server’s latest available geo-redundant backup. You can also configure network settings while restoring using geo-restore by switching between private and public networking options or changing virtual network configurations.
Geo-redundant backup storage
When backups are stored in geo-redundant backup storage, multiple copies stored within the region that hosts your server and replicated to its geo-paired region. This provides better protection and ability to restore your server in a different region in the event of a disaster. In addition, this provides at least 99.99999999999999% (16 9s) durability of backup objects over a given year. Simply enable the geo-redundancy option for Azure Database for MySQL- Flexible Server during server creation to ensure geo-redundant backup storage. Geo-redundancy is supported for servers hosted in any of the Azure paired regions.
Moving from other backup storage options to geo-redundant backup storage
Configuring geo-redundant storage for backup is only allowed during server creation. After the server is provisioned, you can’t change the backup storage redundancy option. However, you can still move your existing backup storage to geo-redundant storage by using the following guidance.
Moving from locally redundant to geo-redundant backup storage - To move your backup storage from locally redundant to geo-redundant storage, perform a point-in-time restore operation and change the Compute + Storage server configuration to enable geo-redundancy for the locally redundant source server. You can restore same-Zone Redundant HA servers as geo-redundant servers in a similar fashion, as the underlying backup storage is also locally redundant.
Moving from zone-redundant to geo-redundant backup storage - Azure Database for MySQL Flexible Server does not support zone-redundant storage to geo-redundant storage conversion through Compute + Storage settings change or point-in-time restore operation. To move your backup storage from zone-redundant storage to geo-redundant storage, the only option is to create a new server and migrate the data using dump and restore.
Geo-restore is the default recovery option when your server is unavailable because of an incident in the region where the server is hosted. If a large-scale incident in a region results in unavailability of your database application, you can restore a server from the geo-redundant backups to a server in any other region. Geo-restore utilizes the most recent backup of the server. There is a delay between when a backup is taken and when it is replicated to a different region. This delay can be up to an hour, so, if a disaster occurs, there can be up to one hour data loss.
Geo-restore is available only if you configured your server for geo-redundant storage and it allows you to restore your server to the geo-paired region. Geo-restore to other regions is currently unsupported. During geo-restore, you can only change the server’s security configuration (firewall rules and virtual network settings).
Geo-redundancy provides better protection and ability to restore your server in a geo-paired region in the event of an unprecedented disaster, ensuring your business does not take a hit and enabling you to build a bulletproof disaster recovery strategy. We believe that using zone redundant high availability together with geo-redundant backups will allow you to achieve your Business Continuity and Disaster Recovery objectives with optimized cost when running your production workloads on Azure Database for MySQL Flexible Server.