Merge pull request #192250 from aditivgupta/lrstogrs

LRS to GRS migration

Author: Maggiemouse1

articles/mysql/flexible-server/concepts-backup-restore.md

@@ -35,16 +35,16 @@ Backup redundancy ensures that your database meets its availability and durabili
 
 - **Zone-redundant backup storage** : When the backups are stored in zone-redundant backup storage, multiple copies are not only stored within the availability zone in which your server is hosted, but are also replicated to another availability zone in the same region. This option can be leveraged for scenarios that require high availability or for restricting replication of data to within a country/region to meet data residency requirements. Also this provides at least 99.9999999999% (12 9's) durability of Backups objects over a given year. One can select Zone-Redundant High Availability option at server create time to ensure zone-redundant backup storage. High Availability for a server can be disabled post create however the backup storage will continue to remain zone-redundant.  
 
-- **Geo-Redundant backup storage** : When the backups are stored in geo-redundant backup storage, multiple copies are not only stored within the region in which your server is hosted, but are also 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. Also this provides at least 99.99999999999999% (16 9's) durability of Backups objects over a given year. One can enable Geo-Redundancy option at server create time to ensure geo-redundant backup storage. Geo redundancy is supported for servers hosted in any of the [Azure paired regions](overview.md#azure-regions). 
+- **Geo-Redundant backup storage** : When the backups are stored in geo-redundant backup storage, multiple copies are not only stored within the region in which your server is hosted, but are also 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. Also this provides at least 99.99999999999999% (16 9's) durability of Backups objects over a given year.One can enable Geo-Redundancy option at server create time to ensure geo-redundant backup storage. Additionally, you can move from locally redundant storage to geo-redundant storage post server create. Geo redundancy is supported for servers hosted in any of the [Azure paired regions](overview.md#azure-regions).
 
 > [!NOTE]
-> Geo-redundancy and zone-redundant High Availability to support zone redundancy is current surfaced as a create time operation only.
+> Zone-redundant High Availability to support zone redundancy is current surfaced as a create time operation only. Currently, for a Zone-redundant High Availability server geo-redundancy can only be enabled/disabled at server create time.
 
-## Moving from other backup storage options to geo-redundant backup storage 
+## Moving from other backup storage options to geo-redundant backup storage
 
-Configuring geo-redundant storage for backup is only allowed during server create. Once the server is provisioned, you cannot change the backup storage redundancy option. However you can still move your existing backups storage to geo-redundant storage using the following suggested ways: 
+You can move your existing backups storage to geo-redundant storage using the following suggested ways:
 
-- **Moving from locally redundant to geo-redundant backup storage** -  In order to move your backup storage from locally redundant storage to geo-redundant storage, you can perform a point-in-time restore operation and change the Compute + Storage server configuration to enable Geo-redundancy for the locally redundant source server. Same Zone Redundant HA servers can also be restored as a geo-redundant server in a similar fashion as the underlying backup storage is locally redundant for the same. 
+- **Moving from locally redundant to geo-redundant backup storage** - In order to move your backup storage from locally redundant storage to geo-redundant storage, you can change the Compute + Storage server configuration from Azure portal to enable Geo-redundancy for the locally redundant source server. Same Zone Redundant HA servers can also be restored as a geo-redundant server in a similar fashion as the underlying backup storage is locally redundant for the same.
 
 - **Moving from zone-redundant to geo-redundant backup storage** - Azure Database for MySQL does not support zone-redundant storage to geo-redundant storage conversion through Compute + Storage settings change or point-in-time restore operation. In order to move your backup storage from zone-redundant storage to geo-redundant storage, creating a new server and migrating the data using [dump and restore](../concepts-migrate-dump-restore.md) is the only supported option.
 
@@ -53,7 +53,7 @@ Configuring geo-redundant storage for backup is only allowed during server creat
 
 Backups are retained based on the backup retention period setting on the server. You can select a retention period of 1 to 35 days with a default retention period is seven days. You can set the retention period during server creation or later by updating the backup configuration using Azure portal.
 
-The backup retention period governs how far back in time can a point-in-time restore operation be performed, since its based on backups available. The backup retention period can also be treated as a recovery window from a restore perspective. All backups required to perform a point-in-time restore within the backup retention period are retained in backup storage. For example - if the backup retention period is set to seven days, the recovery window is considered last seven days. In this scenario, all the backups required to restore the server in last seven days are retained. With a backup retention window of seven days, database snapshots and transaction log backups are stored for the last eight days (1 day prior to the window).
+The backup retention period governs how far back in time can a point-in-time restore operation be performed, since it's based on backups available. The backup retention period can also be treated as a recovery window from a restore perspective. All backups required to perform a point-in-time restore within the backup retention period are retained in backup storage. For example - if the backup retention period is set to seven days, the recovery window is considered last seven days. In this scenario, all the backups required to restore the server in last seven days are retained. With a backup retention window of seven days, database snapshots and transaction log backups are stored for the last eight days (1 day prior to the window).
 
 ## Backup storage cost
 
@@ -126,6 +126,8 @@ Geo-restore is the default recovery option when your server is unavailable becau
 
 During geo-restore, the server configurations that can be changed include only security configuration (firewall rules and virtual network settings). Changing other server configurations such as compute, storage or pricing tier (Basic, General Purpose, or Memory Optimized) during geo-restore is not supported. 
 
+Geo-restore can also be performed on a stopped server leveraging Azure CLI. Read [Restore Azure Database for MySQL - Flexible Server with Azure CLI](how-to-restore-server-cli.md) to learn more about geo-restoring a server with Azure CLI.
+
 The estimated time of recovery depends on several factors including the database sizes, the transaction log size, the network bandwidth, and the total number of databases recovering in the same region at the same time. 
 
 > [!NOTE]

articles/mysql/flexible-server/how-to-restore-server-cli.md

@@ -8,26 +8,27 @@ ms.topic: how-to
 ms.date: 04/01/2021
 ---
 
-# Point-in-time restore of a Azure Database for MySQL Flexible Server with Azure CLI
+# Point-in-time restore of an Azure Database for MySQL Flexible Server with Azure CLI
 
 [[!INCLUDE[applies-to-mysql-flexible-server](../includes/applies-to-mysql-flexible-server.md)]
 
 This article provides step-by-step procedure to perform point-in-time recoveries in flexible server using backups.
 
 ## Prerequisites
 
-- An Azure account with an active subscription. 
+- An Azure account with an active subscription.
 
     [!INCLUDE [flexible-server-free-trial-note](../includes/flexible-server-free-trial-note.md)]
 - Install or upgrade Azure CLI to the latest version. See [Install Azure CLI](/cli/azure/install-azure-cli).
--  Login to Azure account using [az login](/cli/azure/reference-index#az_login) command. Note the **id** property, which refers to **Subscription ID** for your Azure account.
+- Login to Azure account using [az login](/cli/azure/reference-index#az_login) command. Note the **id** property, which refers to **Subscription ID** for your Azure account.
 
     ```azurecli-interactive
     az login
     ````
 
 - If you have multiple subscriptions, choose the appropriate subscription in which you want to create the server using the ```az account set``` command.
 `
+
     ```azurecli
     az account set --subscription <subscription id>
     ```
@@ -43,6 +44,7 @@ This article provides step-by-step procedure to perform point-in-time recoveries
 You can run the following command to restore a server to an earliest existing backup.
 
 **Usage**
+
 ```azurecli
 az mysql flexible-server restore --restore-time
                                  --source-server
@@ -64,9 +66,37 @@ az mysql flexible-server restore \
 --restore-time "2021-03-03T13:10:00Z" \
 --source-server mydemoserver
 ```
+
 Time taken to restore will depend on the size of the data stored in the server.
 
+## Geo-Restore a server from geo-backup to a new server
+
+You can run the following command to geo-restore a server to the most recent backup available.
+
+**Usage**
+
+```azurecli
+az mysql flexible-server geo-restore --source-server
+                                 --location
+                                 [--name]
+                                 [--no-wait]
+                                 [--resource-group]
+                                 [--subscription]
+```
+
+**Example:**
+Geo-restore 'mydemoserver' in region East US to a new server 'mydemoserver-restored' in it’s geo-paired location West US with the same network setting.
+
+```azurecli
+az mysql flexible-server geo-restore \
+--name mydemoserver-restored \
+--resource-group myresourcegroup \
+--location "West US" \
+--source-server mydemoserver
+```
+
 ## Perform post-restore tasks
+
 After the restore is completed, you should perform the following tasks to get your users and applications back up and running:
 
 - If the new server is meant to replace the original server, redirect clients and client applications to the new server
@@ -75,5 +105,5 @@ After the restore is completed, you should perform the following tasks to get yo
 - Configure alerts as appropriate for the newly restore server
 
 ## Next steps
-Learn more about [business continuity](concepts-business-continuity.md)
 
+Learn more about [business continuity](concepts-business-continuity.md)

articles/mysql/flexible-server/whats-new.md

@@ -17,6 +17,16 @@ ms.date: 10/12/2021
 
 This article summarizes new releases and features in Azure Database for MySQL - Flexible Server beginning in January 2021. Listings appear in reverse chronological order, with the most recent updates first.
 
+## March 2022
+
+This release of Azure Database for MySQL - Flexible Server includes the following updates.
+
+- **Migrate from locally redundant backup storage to geo-redundant backup storage for existing flexible server**
+    Azure Database for MySQL - Flexible Server now provides the added flexibility to migrate to geo-redundant backup storage from locally redundant backup storage post server-create to provide higher data resiliency. Enabling geo-redundancy via the server's Compute + Storage blade empowers customers to recover their existing flexible servers from a geographic disaster or regional failure when they can’t access the server in the primary region. With this feature enabled for their existing servers, customers can perform geo-restore and deploy a new server to the geo-paired Azure region leveraging the original server’s latest available geo-redundant backup. [Learn more](concepts-backup-restore.md)
+
+- **Simulate disaster recovery drills for your stopped servers**
+    Azure Database for MySQL - Flexible Server now provides the ability to perform geo-restore on stopped servers helping users simulate disaster recovery drills for their workloads to estimate impact and recovery time.This will help users plan better to meet their disaster recovery and business continuity objectives by leveraging geo-redundancy feature offered by Azure Database for MySQL Flexible Server. [Learn more](how-to-restore-server-cli.md)
+
 ## January 2022
 
 This release of Azure Database for MySQL - Flexible Server includes the following updates.