Updates

johndowns · johndowns · commit adab54d64943 · 2025-07-09T10:14:32.000+12:00
diff --git a/articles/reliability/includes/storage/reliability-storage-architecture-include.md b/articles/reliability/includes/storage/reliability-storage-architecture-include.md
@@ -0,0 +1,16 @@
+---
+ title: include file
+ description: include file
+ author: anaharris-ms
+ ms.service: azure
+ ms.topic: include
+ ms.date: 07/02/2024
+ ms.author: anaharris
+ ms.custom: include file
+---
+
+[Locally redundant storage (LRS)](/azure/storage/common/storage-redundancy?#locally-redundant-storage), the lowest-cost redundancy option, automatically stores and replicates three copies of your data within a single datacenter. Although LRS protects your data against server rack and drive failures, it doesn't account for disasters such as fire or flooding within a datacenter. In the face of such disasters, all replicas of a storage account configured to use LRS might be lost or unrecoverable.
+
+:::image type="content" source="../../media/reliability-storage/locally-redundant-storage.png" alt-text="Diagram showing how data is replicated in availability zones with LRS" lightbox="../../media/reliability-storage/locally-redundant-storage.png" border="false":::
+
+Zone-redundant storage (ZRS) and geo-redundant storage (GRS/GZRS) provide additional protections, and are described in detail in this article.
diff --git a/articles/reliability/includes/storage/reliability-storage-availability-zone-configure-include.md b/articles/reliability/includes/storage/reliability-storage-availability-zone-configure-include.md
@@ -0,0 +1,14 @@
+---
+ title: include file
+ description: include file
+ author: anaharris-ms
+ ms.service: azure
+ ms.topic: include
+ ms.date: 07/02/2024
+ ms.author: anaharris
+ ms.custom: include file
+---
+
+- **Migration**. To convert an existing storage account to ZRS and learn about migration options and requirements, see [Change how a storage account is replicated](/azure/storage/common/redundancy-migration).
+
+- **Disable zone redundancy.** Convert ZRS accounts back to a nonzonal configuration (such as LRS) through the same redundancy configuration change process.
diff --git a/articles/reliability/includes/storage/reliability-storage-availability-zone-down-experience-include.md b/articles/reliability/includes/storage/reliability-storage-availability-zone-down-experience-include.md
@@ -0,0 +1,20 @@
+---
+ title: include file
+ description: include file
+ author: anaharris-ms
+ ms.service: azure
+ ms.topic: include
+ ms.date: 07/02/2024
+ ms.author: anaharris
+ ms.custom: include file
+---
+
+- **Detection and response:** Microsoft automatically detects zone failures and initiates failover processes. No customer action is required for zone-redundant storage accounts.
+
+- **Active requests:** In-flight requests might be dropped during the failover and should be retried. Applications should [implement retry logic](#transient-faults) to handle these temporary interruptions.
+
+- **Expected data loss:** No data loss occurs during zone failures because data is synchronously replicated across multiple zones before write operations complete.
+
+- **Expected downtime:** A small amount of downtime - typically, a few seconds - may occur during automatic failover as traffic is redirected to healthy zones.
+
+- **Traffic rerouting.** Azure automatically reroutes traffic to the remaining healthy availability zones. The service maintains full functionality using the surviving zones with no customer intervention required.
diff --git a/articles/reliability/includes/storage/reliability-storage-availability-zone-failback-include.md b/articles/reliability/includes/storage/reliability-storage-availability-zone-failback-include.md
@@ -0,0 +1,12 @@
+---
+ title: include file
+ description: include file
+ author: anaharris-ms
+ ms.service: azure
+ ms.topic: include
+ ms.date: 07/02/2024
+ ms.author: anaharris
+ ms.custom: include file
+---
+
+When the failed availability zone recovers, Azure Storage automatically restores normal operations across all of the availability zones. During failback, the service automatically ensures data consistency by synchronizing any operations that occurred during the outage period.
diff --git a/articles/reliability/includes/storage/reliability-storage-availability-zone-normal-operations-include.md b/articles/reliability/includes/storage/reliability-storage-availability-zone-normal-operations-include.md
@@ -0,0 +1,14 @@
+---
+ title: include file
+ description: include file
+ author: anaharris-ms
+ ms.service: azure
+ ms.topic: include
+ ms.date: 07/02/2024
+ ms.author: anaharris
+ ms.custom: include file
+---
+
+- **Traffic routing between zones**: Storage with ZRS automatically distributes requests across storage clusters in multiple availability zones. Traffic distribution is transparent to applications and requires no client-side configuration.
+
+- **Data replication between zones**: All write operations to ZRS are replicated synchronously across all availability zones within the region. When you upload or modify data, the operation isn't considered complete until the data has been successfully replicated across all of the availability zones. This synchronous replication ensures strong consistency and zero data loss during zone failures. However, it may result in slightly higher write latency compared to locally redundant storage.
diff --git a/articles/reliability/includes/storage/reliability-storage-availability-zone-support-include.md b/articles/reliability/includes/storage/reliability-storage-availability-zone-support-include.md
@@ -0,0 +1,12 @@
+---
+ title: include file
+ description: include file
+ author: anaharris-ms
+ ms.service: azure
+ ms.topic: include
+ ms.date: 07/02/2024
+ ms.author: anaharris
+ ms.custom: include file
+---
+
+:::image type="content" source="../../media/reliability-storage/zone-redundant-storage.png" alt-text="Diagram showing how data is replicated in the primary region with ZRS" lightbox="../../media/reliability-storage/zone-redundant-storage.png" border="false":::
diff --git a/articles/reliability/includes/storage/reliability-storage-availability-zone-testing-include.md b/articles/reliability/includes/storage/reliability-storage-availability-zone-testing-include.md
@@ -0,0 +1,12 @@
+---
+ title: include file
+ description: include file
+ author: anaharris-ms
+ ms.service: azure
+ ms.topic: include
+ ms.date: 07/02/2024
+ ms.author: anaharris
+ ms.custom: include file
+---
+
+Azure Storage manages replication, traffic routing, failover, and failback for zone-redundant storage. Because this feature is fully managed, you don't need to initiate or validate availability zone failure processes.
diff --git a/articles/reliability/includes/storage/reliability-storage-multi-region-alternative-approach-include.md b/articles/reliability/includes/storage/reliability-storage-multi-region-alternative-approach-include.md
@@ -0,0 +1,12 @@
+---
+ title: include file
+ description: include file
+ author: anaharris-ms
+ ms.service: azure
+ ms.topic: include
+ ms.date: 07/02/2024
+ ms.author: anaharris
+ ms.custom: include file
+---
+
+Azure Storage can be deployed across multiple regions using separate storage accounts in each region. This approach provides flexibility in region selection, the ability to use non-paired regions, and more granular control over replication timing and data consistency. When implementing multiple storage accounts across regions, you need to configure cross-region data replication, implement load balancing and failover policies, and ensure data consistency across regions.
diff --git a/articles/reliability/includes/storage/reliability-storage-multi-region-alternative-reasons-include.md b/articles/reliability/includes/storage/reliability-storage-multi-region-alternative-reasons-include.md
@@ -0,0 +1,22 @@
+---
+ title: include file
+ description: include file
+ author: anaharris-ms
+ ms.service: azure
+ ms.topic: include
+ ms.date: 07/02/2024
+ ms.author: anaharris
+ ms.custom: include file
+---
+
+It may be the case that the cross-region failover capabilities of Azure Storage are unsuitable for the following reasons:
+
+- Your storage account is in a nonpaired region.
+
+- Your business uptime goals aren't satisfied by the recovery time or data loss that the built-in failover options provide.
+
+- You need to fail over to a region that isn't your primary region's pair.
+
+- You need an active/active configuration across regions.
+
+Instead, you can design a cross-region failover solution that's tailored to your needs. A complete treatment of deployment topologies for Azure Storage is outside the scope of this article, but you can consider a multi-region deployment model.
diff --git a/articles/reliability/includes/storage/reliability-storage-multi-region-configure-include.md b/articles/reliability/includes/storage/reliability-storage-multi-region-configure-include.md
@@ -0,0 +1,21 @@
+---
+ title: include file
+ description: include file
+ author: anaharris-ms
+ ms.service: azure
+ ms.topic: include
+ ms.date: 07/02/2024
+ ms.author: anaharris
+ ms.custom: include file
+---
+
+- **Create a new storage account with geo-redundancy.** To create a storage account with geo-redundant configuration, see [Create a storage account](/azure/storage/common/storage-account-create) and select GRS, RA-GRS, GZRS, or RA-GZRS during account creation.
+
+- **Migration.** To convert an existing storage account to geo-redundant storage, see [Change how a storage account is replicated](/azure/storage/common/redundancy-migration) for step-by-step conversion procedures.
+
+  > [!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.
+  >
+  > **To avoid a major data loss**, check the value of the [Last Sync Time property](/azure/storage/common/last-sync-time-get) before initiating an unplanned failover. To evaluate potential data loss, compare the last sync time to the last time at which data was written to the new primary.
+
+- **Disable geo-redundancy.** Convert geo-redundant storage accounts back to single-region configurations (LRS or ZRS) through the same redundancy configuration change process.
diff --git a/articles/reliability/includes/storage/reliability-storage-multi-region-considerations-feature-limitations-include.md b/articles/reliability/includes/storage/reliability-storage-multi-region-considerations-feature-limitations-include.md
@@ -0,0 +1,12 @@
+---
+ title: include file
+ description: include file
+ author: anaharris-ms
+ ms.service: azure
+ ms.topic: include
+ ms.date: 07/02/2024
+ ms.author: anaharris
+ ms.custom: include file
+---
+
+- **Feature limitations**: Some Azure Storage features are not supported or have limitations when using geo-redundant storage or when using customer-managed failover. Review [feature compatibility documentation](/azure/storage/common/storage-disaster-recovery-guidance#unsupported-features-and-services) before implementing geo-redundancy.
diff --git a/articles/reliability/includes/storage/reliability-storage-multi-region-considerations-latency-include.md b/articles/reliability/includes/storage/reliability-storage-multi-region-considerations-latency-include.md
@@ -0,0 +1,12 @@
+---
+ title: include file
+ description: include file
+ author: anaharris-ms
+ ms.service: azure
+ ms.topic: include
+ ms.date: 07/02/2024
+ ms.author: anaharris
+ ms.custom: include file
+---
+
+- **Asynchronous replication latency**: Data replication to the secondary region is asynchronous, which means there's a lag between when data is written to the primary region and when it becomes available in the secondary region. This lag can result in potential data loss (measured as Recovery Point Objective or RPO) if a primary region failure occurs before recent data is replicated. The replication lag is expected to be less than 15 minutes, but this is an estimate and not guaranteed.
diff --git a/articles/reliability/includes/storage/reliability-storage-multi-region-considerations-secondary-no-access-include.md b/articles/reliability/includes/storage/reliability-storage-multi-region-considerations-secondary-no-access-include.md
@@ -0,0 +1,12 @@
+---
+ title: include file
+ description: include file
+ author: anaharris-ms
+ ms.service: azure
+ ms.topic: include
+ ms.date: 07/02/2024
+ ms.author: anaharris
+ ms.custom: include file
+---
+
+- **Secondary region access**: With GRS and GZRS configurations, the secondary region is not accessible for reads until a failover occurs.
diff --git a/articles/reliability/includes/storage/reliability-storage-multi-region-considerations-secondary-read-access-include.md b/articles/reliability/includes/storage/reliability-storage-multi-region-considerations-secondary-read-access-include.md
@@ -0,0 +1,14 @@
+---
+ title: include file
+ description: include file
+ author: anaharris-ms
+ ms.service: azure
+ ms.topic: include
+ ms.date: 07/02/2024
+ ms.author: anaharris
+ ms.custom: include file
+---
+
+- **Secondary region access**: With GRS and GZRS configurations, the secondary region is not accessible for reads until a failover occurs.
+
+    RA-GRS and RA-GZRS configurations provide read access to the secondary region during normal operations, but because of the asynchronous replication latency, might return slightly outdated data.
diff --git a/articles/reliability/includes/storage/reliability-storage-multi-region-down-experience-include.md b/articles/reliability/includes/storage/reliability-storage-multi-region-down-experience-include.md
@@ -0,0 +1,55 @@
+---
+ title: include file
+ description: include file
+ author: anaharris-ms
+ ms.service: azure
+ ms.topic: include
+ ms.date: 07/02/2024
+ ms.author: anaharris
+ ms.custom: include file
+---
+
+This section describes what to expect when a storage account is configured for geo-redundancy and there's an outage in the primary region.
+
+- **Customer-managed failover (unplanned)**: An unplanned failover is intended to be used when storage in the primary region is unavailable.
+
+    - **Detection and response:** In the unlikely event that your storage account is unavailable in your primary region, you can consider initiating a customer-managed unplanned failover. To make this decision, consider the following factors:
+
+      - Whether [Azure Resource Health](/azure/service-health/resource-health-overview) show problems accessing the storage account in your primary region.
+      - Whether Microsoft has advised you to perform failover to another region.
+
+      > [!WARNING]
+      > An unplanned failover [can result in data loss](/azure/storage/common/storage-disaster-recovery-guidance#anticipate-data-loss-and-inconsistencies). Before initiating a customer-managed failover, decide whether the risk of data loss is justified by the restoration of service.
+    
+    - **Active requests:** During the failover process, both the primary and secondary storage account endpoints become temporarily unavailable for both reads and writes. Any active requests might be dropped, and client applications need to retry after the failover completes.
+
+    - **Expected data loss:** During an unplanned failover, it's likely that you will have some data loss. This is because of the asynchronous replication lag, which means that recent writes may not be replicated. You can check the [Last Sync time](/azure/storage/common/last-sync-time-get) to understand how much data could be lost during an unplanned failover. Typically the data loss is expected to be less than 15 minutes, but that's not guaranteed.
+
+    - **Expected downtime:** Failover typically completes within 60 minutes, depending on the account size and complexity.
+
+    - **Traffic rerouting:** As the failover completes, Azure automatically updates the storage account endpoints so that applications don't need to be reconfigured. If your application keeps DNS entries cached, it might be necessary to clear the cache to ensure that the application sends traffic to the new primary. 
+
+    - **Post-failover configuration:** After an unplanned failover completes, your storage account in the destination region uses the LRS tier. If you need to geo-replicate it again, you need to re-enable GRS and wait for the data to be replicated to the new secondary region.
+
+    For more information on initiating customer-managed failover, see [How customer-managed (unplanned) failover works](/azure/storage/common/storage-failover-customer-managed-unplanned) and [Initiate a storage account failover](/azure/storage/common/storage-initiate-account-failover).
+
+- **Customer-managed failover (planned)**: A planned failover is intended to be used when storage remains operational in the primary region, but you need to fail over your whole solution to a secondary region for another reason.
+
+    - **Detection and response:** You're responsible for deciding to fail over. You'd typically do so if you need to fail over between regions even though your storage account is healthy. For example, you might trigger a failover when there's a major outage of another application component that you can't recover from in the primary region.
+
+    - **Active requests:** During the failover process, both the primary and secondary storage account endpoints become temporarily unavailable for both reads and writes. Any active requests might be dropped, and client applications need to retry after the failover completes.
+
+    - **Expected data loss:** No data loss is expected because the failover process waits for all data to be synchronized.
+
+    - **Expected downtime:** Failover typically completes within 60 minutes, depending on the account size and complexity. During the failover process, both the primary and secondary storage account endpoints become temporarily unavailable for both reads and writes.
+
+    - **Traffic rerouting:** As the failover completes, Azure automatically updates the storage account endpoints so that applications don't need to be reconfigured. If your application keeps DNS entries cached, it might be necessary to clear the cache to ensure that the application sends traffic to the new primary. 
+
+    - **Post-failover configuration:** After a planned failover completes, your storage account in the destination region continues to be geo-replicated and remains on the GRS tier.
+
+    For more information on initiating customer-managed failover, see [How customer-managed (planned) failover works](/azure/storage/common/storage-failover-customer-managed-planned) and [Initiate a storage account failover](/azure/storage/common/storage-initiate-account-failover).
+
+- **Microsoft-managed failover**: In the rare case of a major disaster, where Microsoft determines the primary region is permanently unrecoverable, Microsoft might initiate automatic failover to the secondary region. This process is managed entirely by Microsoft and requires no customer action. The amount of time that elapses before failover occurs depends on the severity of the disaster and the time required to assess the situation.
+
+  > [!IMPORTANT]
+  > 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. A Microsoft-managed failover would likely be initiated for an entire region. It can't be initiated for individual storage accounts, subscriptions, or customers. Failover might occur at different times for different Azure services. We recommend you use customer-managed failover.
diff --git a/articles/reliability/includes/storage/reliability-storage-multi-region-failback-include.md b/articles/reliability/includes/storage/reliability-storage-multi-region-failback-include.md
@@ -0,0 +1,18 @@
+---
+ title: include file
+ description: include file
+ author: anaharris-ms
+ ms.service: azure
+ ms.topic: include
+ ms.date: 07/02/2024
+ ms.author: anaharris
+ ms.custom: include file
+---
+
+The failback process differs significantly between Microsoft-managed and customer-managed failover scenarios:
+
+- **Customer-managed failover (unplanned)**: After an unplanned failover, the storage account is configured with locally redundant storage (LRS). In order to fail back, you need to re-establish the GRS relationship and wait for the data to be replicated.
+
+- **Customer-managed failover (planned)**: After a planned failover, the storage account remains geo-replicated (GRS). You can initiate another customer-managed failover in order to fail back to the original primary region. [The same failover considerations apply](#region-down-experience).
+
+- **Microsoft-managed failover**: If Microsoft initiates a failover, it's likely that a significant disaster has occurred in the primary region, and the primary region might not be recoverable. Any timelines or recovery plans depends on the extent of the regional disaster and recovery efforts. You should monitor Azure Service Health communications for details.
diff --git a/articles/reliability/includes/storage/reliability-storage-multi-region-normal-operations-include.md b/articles/reliability/includes/storage/reliability-storage-multi-region-normal-operations-include.md
@@ -0,0 +1,20 @@
+---
+ title: include file
+ description: include file
+ author: anaharris-ms
+ ms.service: azure
+ ms.topic: include
+ ms.date: 07/02/2024
+ ms.author: anaharris
+ ms.custom: include file
+---
+
+This section describes what to expect when a storage account is configured for geo-redundancy and all regions are operational.
+
+- **Traffic routing between regions**: Azure Storage uses an active/passive approach where all write operations and most read operations are directed to the primary region.
+
+  For RA-GRS and RA-GZRS configurations, applications can optionally read from the secondary region by accessing the secondary endpoint, but this requires explicit application configuration and is not automatic. Also, because of the asynchronous replication lag, data in the secondary region might be slightly outdated.
+
+- **Data replication between regions**: Write operations are first committed to the primary region using the configured redundancy type (LRS for GRS/RA-GRS, or ZRS for GZRS/RA-GZRS). After successful completion in the primary region, data is asynchronously replicated to the secondary region where it's stored using locally redundant storage (LRS).
+
+   The asynchronous nature of cross-region replication means there's typically a lag time between when data is written to primary and when it's available in the secondary region. You can monitor the replication time through the [Last Sync Time property](/azure/storage/common/last-sync-time-get).
diff --git a/articles/reliability/includes/storage/reliability-storage-multi-region-region-support-include.md b/articles/reliability/includes/storage/reliability-storage-multi-region-region-support-include.md
@@ -0,0 +1,12 @@
+---
+ title: include file
+ description: include file
+ author: anaharris-ms
+ ms.service: azure
+ ms.topic: include
+ ms.date: 07/02/2024
+ ms.author: anaharris
+ ms.custom: include file
+---
+
+Azure Storage geo-redundant configurations use Azure paired regions for secondary region replication. The secondary region is automatically determined based on your primary region selection and cannot be customized. For a complete list of Azure paired regions, see [Azure paired regions](/azure/reliability/cross-region-replication-azure#azure-paired-regions).
diff --git a/articles/reliability/includes/storage/reliability-storage-multi-region-requirements-include.md b/articles/reliability/includes/storage/reliability-storage-multi-region-requirements-include.md
@@ -0,0 +1,12 @@
+---
+ title: include file
+ description: include file
+ author: anaharris-ms
+ ms.service: azure
+ ms.topic: include
+ ms.date: 07/02/2024
+ ms.author: anaharris
+ ms.custom: include file
+---
+
+Geo-redundant storage, as well as customer initiated failover and failback are available in all [Azure paired regions](../../regions-paired.md) that support general-purpose v2 storage accounts.
diff --git a/articles/reliability/includes/storage/reliability-storage-multi-region-support-failover-types-include.md b/articles/reliability/includes/storage/reliability-storage-multi-region-support-failover-types-include.md
diff --git a/articles/reliability/includes/storage/reliability-storage-multi-region-support-include.md b/articles/reliability/includes/storage/reliability-storage-multi-region-support-include.md
diff --git a/articles/reliability/includes/storage/reliability-storage-multi-region-support-read-access-include.md b/articles/reliability/includes/storage/reliability-storage-multi-region-support-read-access-include.md
diff --git a/articles/reliability/includes/storage/reliability-storage-multi-region-testing-include.md b/articles/reliability/includes/storage/reliability-storage-multi-region-testing-include.md
diff --git a/articles/reliability/includes/storage/reliability-storage-sla-include.md b/articles/reliability/includes/storage/reliability-storage-sla-include.md
diff --git a/articles/reliability/reliability-databricks.md b/articles/reliability/reliability-databricks.md
diff --git a/articles/reliability/reliability-storage-queue.md b/articles/reliability/reliability-storage-queue.md
