More 'last updates'

Author: stevenmatthew

articles/storage/blobs/storage-feature-support-in-storage-accounts.md

@@ -55,8 +55,8 @@ The following table describes whether a feature is supported in a standard gener
 | [Blobfuse](storage-how-to-mount-container-linux.md) | ✅ | ✅ | ✅ | ✅ |
 | [Change feed](storage-blob-change-feed.md) | ✅ |  ⬤ |  ⬤ |  ⬤ |
 | [Custom domains](storage-custom-domain-name.md) | ✅ | 🟦 | 🟦 | 🟦 |
-| [Customer-managed planned failover (preview)](../common/storage-disaster-recovery-guidance.md#customer-managed-planned-failover-preview) | 🟦 | 🟦 |  ⬤ |  ⬤ |
-| [Customer-managed (unplanned) failover](../common/storage-disaster-recovery-guidance.md#customer-managed-unplanned-failover) | ✅ | 🟦 |  ⬤ |  ⬤ |
+| [Customer-managed planned failover (preview)](../common/storage-disaster-recovery-guidance.md#customer-managed-planned-failover-preview) | 🟦 | 🟦 |  ⬤ |  🟦 |
+| [Customer-managed (unplanned) failover](../common/storage-disaster-recovery-guidance.md#customer-managed-unplanned-failover) | ✅ | 🟦 |  ⬤ |  🟦 |
 | [Customer-managed keys with key vault in the same tenant](../common/customer-managed-keys-overview.md?toc=/azure/storage/blobs/toc.json) | ✅ | ✅ | ✅ | ✅ |
 | [Customer-managed keys with key vault in a different tenant (cross-tenant)](../common/customer-managed-keys-overview.md?toc=/azure/storage/blobs/toc.json) | ✅ | ✅ |  ⬤ |  ⬤ |
 | [Customer-provided keys](encryption-customer-provided-keys.md) | ✅ |  ⬤ |  ⬤ |  ⬤ |
@@ -106,7 +106,8 @@ The following table describes whether a feature is supported in a premium block
 | [Blobfuse](storage-how-to-mount-container-linux.md) | ✅ | ✅ | ✅ | ✅ |
 | [Change feed](storage-blob-change-feed.md) | ✅ |  ⬤ |  ⬤ |  ⬤ |
 | [Custom domains](storage-custom-domain-name.md) | ✅ | 🟦 | 🟦 | 🟦 |
-| [Customer-managed account failover](../common/storage-disaster-recovery-guidance.md?toc=/azure/storage/blobs/toc.json) |  ⬤ |  ⬤ |  ⬤ |  ⬤ |
+| [Customer-managed planned failover](../common/storage-failover-customer-managed-planned.md?toc=/azure/storage/blobs/toc.json) |  ⬤ |  ⬤ |  ⬤ |  ⬤ |
+| [Customer-managed unplanned failover](../common/storage-failover-customer-managed-unplanned.md?toc=/azure/storage/blobs/toc.json) |  ⬤ |  ⬤ |  ⬤ |  ⬤ |
 | [Customer-managed keys with key vault in the same tenant](../common/customer-managed-keys-overview.md?toc=/azure/storage/blobs/toc.json) | ✅ | ✅ | ✅ | ✅ |
 | [Customer-managed keys with key vault in a different tenant (cross-tenant)](../common/customer-managed-keys-overview.md?toc=/azure/storage/blobs/toc.json) | ✅ | ✅ |  ⬤ |  ⬤ |
 | [Customer-provided keys](encryption-customer-provided-keys.md) | ✅ |  ⬤ |  ⬤ |  ⬤ |

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

@@ -23,7 +23,7 @@ This article describes how to check the **Last Sync Time** property for your sto
 
 ## 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 an account failover.
+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.
 
 The **Last Sync Time** property is a GMT date/time value.
 

articles/storage/common/redundancy-migration.md

@@ -441,7 +441,11 @@ You can't convert storage accounts to zone-redundancy (ZRS, GZRS, or RA-GZRS) if
 
 After an account failover to the secondary region, it's possible to initiate a failback from the new primary back to the new secondary with PowerShell or Azure CLI (version 2.30.0 or later). [Initiate the failover](storage-initiate-account-failover.md).
 
-If you performed a customer-managed account failover to recover from an outage for your GRS or RA-GRS account, the account becomes locally redundant (LRS) in the new primary region after the failover. Conversion to ZRS or GZRS for an LRS account resulting from a failover isn't supported, even for so-called failback operations. For example, if you perform an account failover from RA-GRS to LRS in the secondary region, and then configure it again as RA-GRS, it remains LRS in the new secondary region (the original primary). If you then perform another account failover to failback to the original primary region, it remains LRS again in the original primary. In this case, you can't perform a conversion to ZRS, GZRS, or RA-GZRS in the primary region. Instead, perform a manual migration to add zone-redundancy.
+If you performed a customer-managed account failover to recover from an outage for your GRS or RA-GRS account, the account becomes locally redundant (LRS) in the new primary region after the failover. Conversion to ZRS or GZRS for an LRS account resulting from a failover isn't supported, even for so-called failback operations. 
+
+For example, if you perform an account failover from RA-GRS to LRS in the secondary region, and then configure it again as RA-GRS, it remains LRS in the new secondary region (the original primary). 
+
+If you then perform another account failover to failback to the original primary region, it remains LRS again in the original primary. In this case, you can't perform a conversion to ZRS, GZRS, or RA-GZRS in the primary region. Instead, perform a manual migration to add zone-redundancy.
 
 ## Downtime requirements