You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<sup>1</sup> Geo-redundancy is lost during unplanned failover and must be manually reconfigured.<br>
98
-
<sup>2</sup> Geo-redundancy is retained during a unplanned failover and doesn't need to be manually reconfigured.
98
+
<sup>2</sup> Geo-redundancy is retained during an unplanned failover and doesn't need to be manually reconfigured.
99
99
100
100
If the data endpoints for the storage services in your storage account become unavailable in the primary region, you can initiate a failover to the secondary region. After the failover is complete, the secondary region becomes the new primary and users can proceed to access data there.
101
101
@@ -111,11 +111,11 @@ To understand the effect of this type of failover on your users and applications
Customer-managed planned failover (preview) can be used to to test your disaster recovery plan. During the planned failover process, the 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.
114
+
Customer-managed planned failover (preview) can be used to test your disaster recovery plan, or to mitigate the effects of a partial networking or compute outage in your primary region. These outages might occur, for example, when workloads in your primary region are disrupted but your storage service endpoints are available.
115
115
116
-
Planned failover can also be used during a partial networking or compute outage in your primary region. These outages might occur, for example, when workloads in your primary region are disrupted but your storage service endpoints are available.
116
+
During the planned failover process, the primary and secondary regions are swapped. The original primary region is demoted and becomes the new secondary region. 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.
117
117
118
-
During customer-managed planned failover and failback, data loss isn't expected as long as the primary and secondary regions are available throughout the entire process. For more detail, see the [Anticipate data loss and inconsistencies](#anticipate-data-loss-and-inconsistencies) section.
118
+
Data loss isn't expected during the failover and failback as long as the primary and secondary regions are available throughout the entire process. For more detail, see the [Anticipating data loss and inconsistencies](#anticipate-data-loss-and-inconsistencies) section.
119
119
120
120
To understand the effect of this type of failover on your users and applications, it's helpful to know what happens during every step of the planned failover and failback processes. For details about how this process works, see [How customer-managed (planned) failover works](storage-failover-customer-managed-planned.md).
121
121
@@ -155,7 +155,7 @@ To understand the effect of this type of failover on your users and applications
155
155
156
156
### Microsoft-managed failover
157
157
158
-
Microsoft may potentially initiate a regional failover in the event of an extreme circumstance such as a catastrophic disaster that impacts an entire geo region. During these events, no action on your part is required. If your storage account is configured for RA-GRS or RA-GZRS, your applications can read from the secondary region during a Microsoft-managed failover. However, you don't have write access to your storage account until the failover process is complete.
158
+
Microsoft may initiate a regional failover in extreme circumstances, such as a catastrophic disaster that impacts an entire geo region. During these events, no action on your part is required. If your storage account is configured for RA-GRS or RA-GZRS, your applications can read from the secondary region during a Microsoft-managed failover. However, you don't have write access to your storage account until the failover process is complete.
159
159
160
160
> [!IMPORTANT]
161
161
> Use customer-managed failover options to develop, test, and implement your disaster recovery plans. **Do not** rely on Microsoft-managed failover, which might only be used in extreme circumstances.
@@ -168,7 +168,7 @@ Microsoft may potentially initiate a regional failover in the event of an extrem
168
168
169
169
Because data is written asynchronously from the primary region to the secondary region, there's always a delay before a write to the primary region is copied to the secondary. If the primary region becomes unavailable, it's possible that the most recent writes might not yet be copied to the secondary.
170
170
171
-
When a failover occurs, all data in the primary region is lost as the secondary region becomes the new primary. All data already copied to the secondary region is maintained when the failover happens. However, any data written to the primary that doesn't yet exist within the secondary region is lost permanently.
171
+
When an unplanned failover occurs, all data in the primary region is lost as the secondary region becomes the new primary. All data already copied to the secondary region is maintained when the failover happens. However, any data written to the primary that doesn't yet exist within the secondary region is lost permanently.
172
172
173
173
The new primary region is configured to be locally redundant (LRS) after the failover.
174
174
@@ -209,7 +209,9 @@ Customer-managed failover is supported for general-purpose v2 standard tier stor
209
209
210
210
The time it takes for a customer-initiated failover to complete after being initiated can vary, although it typically takes less than one hour.
211
211
212
-
A planned customer-managed failover doesn't lose its geo-redundancy after a failover and subsequent failback, but an unplanned customer-managed failover does. When a customer-managed (unplanned) failover is initiated, your storage account is automatically converted to locally redundant storage (LRS) in the new primary region, and the storage account in the original primary region is deleted.
212
+
A planned customer-managed failover doesn't lose its geo-redundancy after a failover and subsequent failback, but an unplanned customer-managed failover does.
213
+
214
+
Initiating a customer-managed unplanned failover automatically converts your storage account to locally redundant storage (LRS) within a new primary region, and deletes the storage account in the original primary region.
213
215
214
216
You can re-enable geo-redundant storage (GRS) or read-access geo-redundant storage (RA-GRS) for the account, but re-replicating data to the new secondary region incurs a charge. Additionally, any archived blobs need to be rehydrated to an online tier before the account can be reconfigured for geo-redundancy. This rehydration also incurs an extra charge. For more information about pricing, see:
215
217
@@ -248,12 +250,24 @@ All geo-redundant offerings support Microsoft-managed failover. In addition, som
248
250
249
251
The following features and services aren't supported for account failover:
250
252
251
-
- Azure File Sync doesn't support customer initiated storage account failover. Storage accounts containing Azure file shares being used as cloud endpoints in Azure File Sync shouldn't be failed over. Doing so will cause sync to stop working and may also cause unexpected data loss in the case of newly tiered files. For more information, see [Best practices for disaster recovery with Azure File Sync](../file-sync/file-sync-disaster-recovery-best-practices.md#geo-redundancy) for details.
253
+
- Azure File Sync doesn't support customer initiated storage account failover. Storage accounts used as cloud endpoints for Azure File Sync shouldn't be failed over. Failover disrupts file sync and might cause the unexpected data loss of newly tiered files. For more information, see [Best practices for disaster recovery with Azure File Sync](../file-sync/file-sync-disaster-recovery-best-practices.md#geo-redundancy) for details.
252
254
- A storage account containing premium block blobs can't be failed over. Storage accounts that support premium block blobs don't currently support geo-redundancy.
253
255
- Customer-managed failover isn't supported for either the source or the destination account in an [object replication policy](../blobs/object-replication-overview.md).
254
256
- An account with SSH File Transfer Protocol (SFTP) enabled can't be failed over. To fail over an SFTP-enabled account, you must first [disable SFTP for the account](../blobs/secure-file-transfer-protocol-support-how-to.md#disable-sftp-support). You can [re-enable sftp](../blobs/secure-file-transfer-protocol-support-how-to.md#enable-sftp-support) if you want to resume using it after the failover is complete.
255
257
- Network File System (NFS) 3.0 (NFSv3) isn't supported for storage account failover. You can't create a storage account configured for global-redundancy with NFSv3 enabled.
256
258
259
+
The following table can be used to reference feature support.
Storage account failover is a temporary solution to a service outage and shouldn't be used as part of your data migration strategy. For information about how to migrate your storage accounts, see [Azure Storage migration overview](storage-migration-overview.md).
Copy file name to clipboardExpand all lines: articles/storage/common/storage-failover-customer-managed-planned.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,7 +7,7 @@ author: stevenmatthew
7
7
8
8
ms.service: azure-storage
9
9
ms.topic: conceptual
10
-
ms.date: 04/29/2024
10
+
ms.date: 06/05/2024
11
11
ms.author: shaas
12
12
ms.subservice: storage-common-concepts
13
13
ms.custom:
@@ -20,9 +20,9 @@ Current: 100 (1779/0)
20
20
21
21
# How customer-managed planned failover (preview) works
22
22
23
-
Customer-managed planned failover (preview) can be used to test your disaster recovery plan. During the planned failover process, the 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.
23
+
Customer-managed planned failover (preview) can be used to test your disaster recovery plan, or to mitigate the effects of a partial networking or compute outage in your primary region. These outages might occur, for example, when workloads in your primary region are disrupted but your storage service endpoints are available.
24
24
25
-
Customer-managed planned failover (preview) can also be used during a partial networking or compute outage in your primary region. These outages might occur, for example, when an outage in your primary region prevents your workloads from functioning properly, but leaves your storage service endpoints available.
25
+
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.
26
26
27
27
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).
> In some cases, a storage account's Last Sync Time (LST) value may be reported as NULL when Azure Files data is present.
15
+
> After a planned failover, a storage account's Last Sync Time (LST) value might appear stale or be reported as NULL when Azure Files data is present.
16
16
>
17
17
> System snapshots are periodically created in a storage account's secondary region to maintain consistent recovery points used during failover and failback. Initiating customer-managed planned failover causes the original primary region becomes the new secondary. In some cases there are no system snapshots available on new secondary after the planned failover completes, causing the account's overall LST value to appear stale or be displayed as `Null`.
0 commit comments