Overview
Backup and restore is the cornerstone of our business continuity and disaster recovery offering for Azure Database for MySQL - Flexible Server. However, many enterprises are bound by compliance and auditing requirements for managing their data backups, so providing greater visibility into when full automated backups are taken is critical, as is the ability to quickly restore servers using those backups.
We’re delighted to announce that the latest release of Azure Database for MySQL - Flexible Server lifts the cloak of invisibility from a server’s automated full backups. The new functionality allows customers to view backup history within the retention period and the ability to use a full server backup to quickly restore a server!
A “memory palace” for Flexible Server’s full automated backups
Fictional detective Sherlock Holmes consciously deposited selected memories into his “memory palace” so that he could later recall the major facts relevant to a case. We’re using a similar approach to upgrade the Flexible Server experience. To safeguard customers’ data, Flexible Server creates full server backups on a daily basis and stores them securely in redundant storage. These full backups are snapshot-based, and the backup activity does not interfere with production workloads or maintenance windows. Customers can now view and use these full backups in the Flexible Server’s memory palace to restore servers in the fastest possible time.
View available full backups
We’re launching a dedicated Backup and Restore blade in the Azure portal. This blade lists the backups available within the server’s retention period, effectively providing customers with single pane view for managing a server’s backups and consequent restores.
Customers can use this blade to 1) view the completion timestamps for all available full backups within the server’s retention period and 2) perform restore operations using these full backups. The list of available backups includes all full automated backups within the retention period, a timestamp showing the successful completion, a timestamp indicating how long a backup will be retained, and a restore action.
Note: Currently, you cannot export these full backup files; they can only be used for Flexible Server restore operations.
In addition to taking full backups, Flexible Server takes transaction log backups every five minutes, which facilitates point-in-time recovery for any chosen timestamp. While these transaction log backups do not appear on the Backup and Restore blade, they're used to support point-in-time recovery options.
Fastest restore points
Point-in-time restore serves as a life jacket for enterprises, allowing recovery from accidental database deletion and data corruption scenarios. Though Flexible Server offers the latest restore point and a custom restore point as recovery options, the estimated time of recovery has been heavily dependent on the size of the transaction log backup that needs to be replayed from the time of last successful full backup. Since customers previously had no visibility into when the latest full backup was taken while selecting a restore point, they couldn’t really control or monitor their restore times. This in turn often led to selecting abstract restore points with longer restore completion times.
Developers and database/IT administrators always scramble to resurrect and restore their servers in the shortest possible time to ensure business continuity. To better serve these users, we’re also launching “fastest restore points” in our point-in-time restore experience on the Azure portal. This feature enables customers to identify the best possible restore time for a specific server instance. With the fastest restore point option, users can restore a Flexible Server instance in the fastest time possible on a given day within the server’s retention period. Ensuring the fastest restore possible is just a matter of choosing the restore point-in-time at which a full backup is completed. This restore operation will simply restore the full snapshot backup without requiring restore or recovery of logs.
Let’s look at an example. Given a 100 GB database and binlog disk usage of around 11.5 MB/hour, 90 mins represents the "worst case" restore time, if replaying 24 hours of binlog is required. With the fastest restore point option, we’ve successfully reduced this time to a mere five minutes!
Bonus
Furthering our vision of providing our customers with a simplified backup management experience, the Backup and Restore blade will also include section dedicated to listing your most frequently asked questions, together with answers. This should provide customers with answers to most questions about backup directly within the Azure portal as they manage their server instance backups. In addition, selecting the question mark icon for FAQs on the top menu provides access to even more related detail!
Summary
Backup and restore functionality protects data from accidental corruption or deletion, so it’s an essential part of any business continuity strategy. By exposing the history of full backups in Flexible Server and providing greater visibility into the backup process to help address auditing and regulatory requirements, we’re aiming to make server management even more easier. In addition, using the fastest restore points feature should help to eliminate the anxious waiting times for restore operations to complete and provide more predictable restore times based on the size of your database.
Rest assured that this is just the first step in upgrading our backup and restore experience. More is definitely yet to come, so stay tuned for additional exciting updates in this space!
If you have any feedback or questions about the information provided above, please leave a comment below or email us at AskAzureDBforMySQL@service.microsoft.com. Thank you!
Posted at https://sl.advdat.com/3bBhGgD