Skip to content

Commit f87371b

Browse files
committed
CHanges to the include to address the Files bug
1 parent 7b5e20f commit f87371b

File tree

3 files changed

+14
-14
lines changed

3 files changed

+14
-14
lines changed

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -25,7 +25,7 @@ Microsoft strives to ensure that Azure services are always available. However, u
2525
- [Data protection](../blobs/data-protection-overview.md)
2626
- [Backup and restore](../../backup/index.yml)
2727
- [Data redundancy](storage-redundancy.md)
28-
- [Failover](#plan-for-storage-account-failover)
28+
- [Failover](#plan-for-failover)
2929
- [Designing applications for high availability](#design-for-high-availability)
3030

3131
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.

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

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -27,11 +27,11 @@ To learn more about account failover, see [Azure storage disaster recovery plann
2727

2828
## Prerequisites
2929

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.
3131

3232
- **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.
3333
- **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.
3535
- **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.
3636
- **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).
3737
- **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.

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

Lines changed: 11 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -12,14 +12,14 @@ ms.custom: "include file", references_regions
1212
---
1313

1414
> [!IMPORTANT]
15-
> 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

Comments
 (0)