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
-[Designing applications for high availability](#design-for-high-availability)
30
30
31
31
This article describes the options available for globally redundant storage accounts, and provides recommendations for developing highly available applications and testing your disaster recovery plan.
Copy file name to clipboardExpand all lines: articles/storage/common/storage-initiate-account-failover.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,11 +27,11 @@ To learn more about account failover, see [Azure storage disaster recovery plann
27
27
28
28
## Prerequisites
29
29
30
-
Review these important topics detailed in the [disaster recovery guidance](storage-disaster-recovery-guidance.md#plan-for-storage-account-failover) article before initiating a customer-managed failover.
30
+
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.
31
31
32
32
-**Potential data loss**: Data loss should be expected during an unplanned storage account failover. For details on the implications of an unplanned account failover and to how to prepare for data loss, see the [Anticipate data loss and inconsistencies](storage-disaster-recovery-guidance.md#anticipate-data-loss-and-inconsistencies) section.
33
33
-**Geo-redundancy**: Before you can perform a failover, your storage account must be configured for geo-redundancy. Initial synchronization from the primary to the secondary region must complete before the failover process can begin. If your account isn't configured for geo-redundancy, you can change it by following the steps described within the [Change how a storage account is replicated](redundancy-migration.md) article. For more information about Azure storage redundancy options, see the [Azure Storage redundancy](storage-redundancy.md) article.
34
-
-**Understand the different types of account failover**: There are two types of customer-managed failover. See the [Plan for failover](storage-disaster-recovery-guidance.md#plan-for-storage-account-failover) article to learn about potential use cases for each type, and how they differ.
34
+
-**Understand the different types of account failover**: There are two types of customer-managed failover. See the [Plan for failover](storage-disaster-recovery-guidance.md#plan-for-failover) article to learn about potential use cases for each type, and how they differ.
35
35
-**Plan for unsupported features and services**: Review the [Unsupported features and services](storage-disaster-recovery-guidance.md#unsupported-features-and-services) article and take appropriate action before initiating a failover.
36
36
-**Supported storage account types**: Ensure that your storage account type can be used to initiate a failover. See [Supported storage account types](storage-disaster-recovery-guidance.md#supported-storage-account-types).
37
37
-**Set your expectations for timing and cost**: The time it takes the customer-managed failover process to complete can vary, but typically takes less than one hour. An unplanned failover results in the loss of geo-redundancy configuration. Reconfiguring geo-redundant storage (GRS) typically incurs extra time and cost. For more information, see the [time and cost of failing over](storage-disaster-recovery-guidance.md#the-time-and-cost-of-failing-over) section.
> In some cases, a storage account's Last Sync Time (LST) value may be reported as NULL.
16
-
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 failover causes the original primary region becomes the new secondary. In some cases there are no system snapshots available on new secondary after the failover completes, causing the account's overall LST value to be displayed as `Null`.
18
-
19
-
Because user activities such as creating, modifying, or deleting objects can trigger snapshot creation, any account on which these activities occur after failover will not require addtional attention. However, accounts having no snapshots or user activity may continue to display a `Null` LST value until system snapshot creation is triggered.
20
-
21
-
If necessary, perform one of the following activities to trigger snapshot creation. Upon completion, your account should display a valid LST value within 30 minutes' time.
22
-
23
-
- Mount the share, then open any file for reading.
24
-
- Upload a test or sample file to the share.
25
-
- Create a share snapshot for the share from the Azure portal.
15
+
> In some cases, a storage account's Last Sync Time (LST) value may be reported as NULL when Azure Files data is present.
16
+
>
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`.
18
+
>
19
+
> 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 addtional attention. However, accounts having no snapshots or user activity may continue to display a `Null` LST value until system snapshot creation is triggered.
20
+
>
21
+
>If necessary, perform one of the following activities to trigger snapshot creation. Upon completion, your account should display a valid LST value within 30 minutes' time.
22
+
>
23
+
> - Mount the share, then open any file for reading.
24
+
> - Upload a test or sample file to the share.
25
+
> - Create a share snapshot for the share from the Azure portal.
0 commit comments