Updated last-sync-time

Author: stevenmatthew

articles/storage/common/last-sync-time-get.md

@@ -15,15 +15,15 @@ ms.subservice: storage-common-concepts
 
 # Check the Last Sync Time property for a storage account
 
-When you configure a storage account, you can specify that your data is copied to a secondary region that is hundreds of miles from the primary region. Geo-replication offers durability for your data in the event of a significant outage in the primary region, such as a natural disaster. If you additionally enable read access to the secondary region, your data remains available for read operations if the primary region becomes unavailable. You can design your application to switch seamlessly to reading from the secondary region if the primary region is unresponsive.
+Geo-replication offers durability for your data, even during natural disasters and other significant outages in your primary region. When you configure a storage account, you can choose to have your data copied to a secondary region that is hundreds of miles from the primary region. In addition, you can choose to enable read access to the secondary region, ensuring that your data remains available for read operations if the primary region becomes unavailable. This approach enables you to [design your highly available application](../blobs/storage-create-geo-redundant-storage.md) to switch seamlessly to reading from the secondary region if the primary region is unresponsive.
 
 Geo-redundant storage (GRS) and geo-zone-redundant storage (GZRS) both replicate your data asynchronously to a secondary region. For read access to the secondary region, enable read-access geo-redundant storage (RA-GRS) or read-access geo-zone-redundant storage (RA-GZRS). For more information about the various options for redundancy offered by Azure Storage, see [Azure Storage redundancy](storage-redundancy.md).
 
 This article describes how to check the **Last Sync Time** property for your storage account so that you can evaluate any discrepancy between the primary and secondary regions.
 
 ## About the Last Sync Time property
 
-Because geo-replication is asynchronous, it is possible that data written to the primary region has not yet been written to the secondary region at the time an outage occurs. The **Last Sync Time** property indicates the most recent time that data from the primary region is guaranteed to have been written to the secondary region. For accounts that have a hierarchical namespace, the same **Last Sync Time** property also applies to the metadata managed by the hierarchical namespace, including ACLs. All data and metadata written prior to the last sync time  is available on the secondary, while data and metadata written after the last sync time may not have been written to the secondary, and may be lost. Use this property in the event of an outage to estimate the amount of data loss you may incur by initiating a customer-managed (unplanned) failover.
+Because geo-replication is asynchronous, it's possible that data written to the primary region hasn't yet been written to the secondary region at the time an outage occurs. The **Last Sync Time** property indicates the most recent time that data from the primary region is guaranteed to have been written to the secondary region. For accounts that have a hierarchical namespace, the same **Last Sync Time** property also applies to the metadata managed by the hierarchical namespace, including ACLs. All data and metadata written prior to the last sync time  is available on the secondary, while data and metadata written after the last sync time may not have been written to the secondary, and may be lost. Use this property in the event of an outage to estimate the amount of data loss you may incur by initiating a customer-managed (unplanned) failover.
 
 The **Last Sync Time** property is a GMT date/time value.
 

articles/storage/common/redundancy-migration.md

@@ -132,7 +132,7 @@ az storage account update \
 You can also add or remove zone redundancy to your storage account. To change between locally redundant and zone-redundant storage with Azure CLI, call the [az storage account migration start](/cli/azure/storage/account/migration#az-storage-account-migration-start) command and specify the `--sku` parameter:
 
 ```azurecli-interactive
-az storage account migration start  \
+az storage account migration start \
     -- account-name <string> \
     -- g <string> \
     --sku <string> \
@@ -142,9 +142,9 @@ az storage account migration start  \
 To track the current migration status of the conversion initiated on your storage account, use the [az storage account migration show](/cli/azure/storage/account/migration#az-storage-account-migration-show) command:
 
 ```azurecli-interactive
-az storage account migration show 
-    --account-name <string>
-    - g <sting>
+az storage account migration show \
+    --account-name <string> \
+    - g <sting> \
     -n "default"
 ```
 
@@ -250,12 +250,13 @@ Get-AzStorageAccountMigration
 
 # [Azure CLI](#tab/azure-cli)
 
-To track the current migration status of the conversion initiated on your storage account, call the [Get-AzStorageAccountMigration](/powershell/module/az.storage/get-azstorageaccountmigration) cmdlet:
+To track the current migration status of the conversion initiated on your storage account, use the [az storage account migration show](/cli/azure/storage/account/migration#az-storage-account-migration-show) command:
 
-```powershell
-Get-AzStorageAccountMigration
-   -AccountName <String>
-   -ResourceGroupName <String>
+```azurecli-interactive
+az storage account migration show \
+    --account-name <string> \
+    - g <sting> \
+    -n "default"
 ```
 
 ---

articles/storage/common/storage-failover-customer-managed-planned.md

@@ -23,10 +23,10 @@ Current: 100 (1779/0)
 There are many scenarios for which planned failover is ideal. These scenarios include: 
 
 - Disaster recovery (DR) planning and testing.
-- Recovery during an outage that doesn't affect your primary region's storage service endpoints, but prevents another Microsoft or 3rd party service from providing access to your workloads.
-- To proactively prepare for large-scale disasters, such as a hurricane, that may impact a region.
+- Proactive preparation for large-scale disasters, such as hurricanes, that may impact a region.
+- Recovery from an outage that doesn't affect your primary region's storage service endpoints, but prevents other services from providing access to your workloads.
 
-During the planned failover process, your storage account's  primary and secondary regions are swapped. The original primary region is demoted and becomes the new secondary. At the same time, the original secondary region is promoted and becomes the new primary. After the failover completes, users can proceed to access data in the new primary region and administrators can validate their disaster recovery plan. The storage account must be available in both the primary and secondary regions before a planned failover can be initiated.
+During the planned failover process, your storage account's primary and secondary regions are swapped. The original primary region is demoted and becomes the new secondary while the original secondary region is promoted and becomes the new primary. <!--After the failover completes, users can proceed to access data in the new primary region and administrators can validate their disaster recovery plan.--> The storage account must be available in both the primary and secondary regions before a planned failover can be initiated.
 
 This article describes what happens during a customer-managed planned failover and failback at every stage of the process. To understand how a failover due to an unexpected storage endpoint outage works, see [How customer-managed (unplanned) failover](storage-failover-customer-managed-unplanned.md).