Merge pull request #292657 from stevenmatthew/unplannedFailoverGA-0106

unplannedFailoverGA-0106

Author: prmerger-automator[bot]

articles/storage/blobs/secure-file-transfer-protocol-known-issues.md

@@ -79,7 +79,7 @@ To learn more, see [SFTP permission model](secure-file-transfer-protocol-support
 
 - Maximum file upload size via the SFTP endpoint is 500 GB.
 
-- Customer-managed account failover is supported at the preview level in select regions. For more information, see [Azure storage disaster recovery planning and failover](../common/storage-disaster-recovery-guidance.md#hierarchical-namespace-hns).
+- Customer-managed planned failover is supported at the preview level in select regions. For more information, see [Azure storage disaster recovery planning and failover](../common/storage-disaster-recovery-guidance.md).
 
 - To change the storage account's redundancy/replication settings, SFTP must be disabled. SFTP may be re-enabled once the conversion has completed.
 

articles/storage/common/storage-disaster-recovery-guidance.md

@@ -7,7 +7,7 @@ author: stevenmatthew
 
 ms.service: azure-storage
 ms.topic: conceptual
-ms.date: 08/05/2024
+ms.date: 01/06/2025
 ms.author: shaas
 ms.subservice: storage-common-concepts
 ms.custom: references_regions
@@ -65,13 +65,13 @@ Each type of failover has a unique set of use cases, corresponding expectations
 
 | Type                                   | Failover Scope  | Use case | Expected data loss | Hierarchical Namespace (HNS) supported |
 |----------------------------------------|-----------------|----------|--------------------|----------------------------------------|
-| Customer-managed planned failover (preview) | Storage account | The storage service endpoints for the primary and secondary regions are available, and you want to perform disaster recovery testing. <br></br> The storage service endpoints for the primary region are available, but another service is preventing your workloads from functioning properly.<br><br>To proactively prepare for large-scale disasters, such as a hurricane, that might affect a region. | [No](#anticipate-data-loss-and-inconsistencies)  | [Yes <br> *(In preview)*](#hierarchical-namespace-hns) |
-| Customer-managed (unplanned) failover              | Storage account | The storage service endpoints for the primary region become unavailable, but the secondary region is available. <br></br> You received an Azure Advisory in which Microsoft advises you to perform a failover operation of storage accounts potentially affected by an outage. | [Yes](#anticipate-data-loss-and-inconsistencies) | [Yes <br> *(In preview)*](#hierarchical-namespace-hns) |
-| Microsoft-managed                      | Entire region   | The primary region becomes unavailable due to a significant disaster, but the secondary region is available. | [Yes](#anticipate-data-loss-and-inconsistencies) | [Yes](#hierarchical-namespace-hns) |
+| Customer-managed planned failover (preview) | Storage account | The storage service endpoints for the primary and secondary regions are available, and you want to perform disaster recovery testing. <br></br> The storage service endpoints for the primary region are available, but another service is preventing your workloads from functioning properly.<br><br>To proactively prepare for large-scale disasters, such as a hurricane, that might affect a region. | [No](#anticipate-data-loss-and-inconsistencies)  | Yes <br> *(In preview)* |
+| Customer-managed (unplanned) failover              | Storage account | The storage service endpoints for the primary region become unavailable, but the secondary region is available. <br></br> You received an Azure Advisory in which Microsoft advises you to perform a failover operation of storage accounts potentially affected by an outage. | [Yes](#anticipate-data-loss-and-inconsistencies) | Yes |
+| Microsoft-managed                      | Entire region   | The primary region becomes unavailable due to a significant disaster, but the secondary region is available. | [Yes](#anticipate-data-loss-and-inconsistencies) | Yes |
 
 The following table compares a storage account's redundancy state after each type of failover:
 
-| Result of failover on...                | Customer-managed planned failover (preview)  | Customer-managed (unplanned) failover                                               |
+| Result of failover on...                | Customer-managed planned failover (preview)  | Customer-managed (unplanned) failover                                   |
 |-----------------------------------------|----------------------------------------------|-------------------------------------------------------------------------|
 | ...the secondary region                 | The secondary region becomes the new primary | The secondary region becomes the new primary                            |
 | ...the original primary region          | The original primary region becomes the new secondary |The copy of the data in the original primary region is deleted  |
@@ -200,10 +200,6 @@ All geo-redundant offerings support Microsoft-managed failover. In addition, som
 >
 > During a disaster that affects the primary region, Microsoft will manage the failover for classic storage accounts. For more information, see [Microsoft-managed failover](#microsoft-managed-failover).
 
-#### Hierarchical namespace (HNS)
-
-[!INCLUDE [updated-for-az](../../../includes/storage-failover-unplanned-hns-preview-include.md)]
-
 ### Unsupported features and services
 
 The following features and services aren't supported for customer-managed failover:
@@ -217,10 +213,10 @@ The following table can be used to reference feature support.
 
 |                                  | Planned failover    | Unplanned failover  |
 |----------------------------------|---------------------|---------------------|
-| **Azure Data Lake Storage**                    | Supported (preview) | Supported (preview) |
+| **Azure Data Lake Storage**                    | Supported (preview) | Supported |
 | **Change Feed**                  | Unsupported         | Supported           |
 | **Object Replication**           | Unsupported         | Unsupported         |
-| **SFTP**                         | Supported (preview) | Supported (preview) |
+| **SFTP**                         | Supported (preview) | Supported           |
 | **NFSv3**                        | GRS is unsupported  | GRS is unsupported  |
 | **Storage Actions**              | Supported<sup>1</sup> | Supported<sup>1</sup> | 
 | **Point-in-time restore (PITR)** | Unsupported         | Supported           |

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

@@ -23,8 +23,6 @@ Customer-managed (unplanned) failover enables you to fail over your entire geo-r
 
 This article describes what happens during a customer-managed (unplanned) failover and failback at every stage of the process.
 
-[!INCLUDE [updated-for-az](../../../includes/storage-failover-unplanned-hns-preview-include.md)]
-
 ## Redundancy management during unplanned failover and failback
 
 > [!TIP]
@@ -36,7 +34,7 @@ During the customer-managed (unplanned) failover process, the Domain Name System
 
 The original and current redundancy configurations are stored within the storage account's properties. This functionality allows you to return to your original configuration when you fail back. For a complete list of resulting redundancy configurations, read [Recovery planning and failover](storage-disaster-recovery-guidance.md#plan-for-failover).
 
-To regain geo-redundancy after a failover, you need to reconfigure your account as GRS.<!--Keep in mind that GZRS isn't a post-failover option because your storage account utilizes LRS after the failover completes.--> After the account is reconfigured for geo-redundancy, Azure immediately begins copying data from the new primary region to the new secondary. If you configure your storage account for read access to the secondary region, that access is available. However, replication from the primary to the secondary region might take some time to complete.
+To regain geo-redundancy after a failover, you need to reconfigure your account as GRS. After the account is reconfigured for geo-redundancy, Azure immediately begins copying data from the new primary region to the new secondary. If you configure your storage account for read access to the secondary region, that access is available. However, replication from the primary to the secondary region might take some time to complete.
 
 > [!WARNING]
 > After your account is reconfigured for geo-redundancy, it may take a significant amount of time before existing data in the new primary region is fully copied to the new secondary.

articles/storage/common/storage-initiate-account-failover.md

@@ -7,7 +7,7 @@ author: stevenmatthew
 
 ms.service: azure-storage
 ms.topic: how-to
-ms.date: 06/13/2024
+ms.date: 01/06/2025
 ms.author: shaas
 ms.subservice: storage-common-concepts
 ---
@@ -18,8 +18,6 @@ Microsoft strives to ensure that Azure services are always available. However, u
 
 This article shows how to initiate an account failover for your storage account using the Azure portal, PowerShell, or the Azure CLI. To learn more about account failover, see [Azure storage disaster recovery planning and failover](storage-disaster-recovery-guidance.md).
 
-[!INCLUDE [updated-for-az](../../../includes/storage-failover-unplanned-hns-preview-include.md)]
-
 ## Prerequisites
 
 Review these important topics detailed in the [disaster recovery guidance](storage-disaster-recovery-guidance.md#plan-for-failover) article before initiating a customer-managed failover.

includes/storage-failover-user-unplanned-preview-lst.md

@@ -18,7 +18,7 @@ ms.custom: "include file", references_regions
 >
 > Because user activities such as creating, modifying, or deleting objects can trigger snapshot creation, any account on which these activities occur after planned failover will not require additional attention. However, accounts having no snapshots or user activity may continue to display a `Null` LST value until system snapshot creation is triggered.
 >
->If necessary, perform one of the following activities **for each share within a storage account** to trigger snapshot creation. Upon completion, your account should display a valid LST value within 30 minutes' time.
+> If necessary, perform one of the following activities **for each share within a storage account** to trigger snapshot creation. Upon completion, your account should display a valid LST value within 30 minutes' time.
 >
 >   - Mount the share, then open any file for reading.
 >   - Upload a test or sample file to the share.