changes based on pre-publish preview

Author: jimmart-dev

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

@@ -23,21 +23,21 @@ Microsoft strives to ensure that Azure services are always available. However, u
 - [Failover](#plan-for-storage-account-failover)
 - [Designing applications for high availability](#design-for-high-availability)
 
-This article focuses on failover for globally-redundant storage accounts (GRS, GZRS, and RA-GZRS), and how to design your applications to be highly available if there's an outage and subsequent failover.
+This article focuses on failover for globally redundant storage accounts (GRS, GZRS, and RA-GZRS), and how to design your applications to be highly available if there's an outage and subsequent failover.
 
 ## Choose the right redundancy option
 
 Azure Storage maintains multiple copies of your storage account to ensure durability and high availability. Which redundancy option you choose for your account depends on the degree of resiliency you need for your applications.
 
-With locally-redundant storage (LRS), three copies of your storage account are automatically stored and replicated within a single datacenter. With zone-redundant storage (ZRS), a copy is stored and replicated in each of three separate availability zones within the same region. For more information about availability zones, see [Azure availability zones](../../availability-zones/az-overview.md).
+With locally redundant storage (LRS), three copies of your storage account are automatically stored and replicated within a single datacenter. With zone-redundant storage (ZRS), a copy is stored and replicated in each of three separate availability zones within the same region. For more information about availability zones, see [Azure availability zones](../../availability-zones/az-overview.md).
 
 Recovery of a single copy of a storage account occurs automatically with LRS and ZRS.
 
-### Globally-redundant storage and failover
+### globally redundant storage and failover
 
-With globally-redundant storage (GRS, GZRS, and RA-GZRS), Azure copies your data asynchronously to a secondary geographic region at least hundreds of miles away. This allows you to recover your data if there's an outage in the primary region. A feature that distinguishes globally-redundant storage from LRS and ZRS is the ability to fail over to the secondary region if there's an outage in the primary region. The process of failing over updates the DNS entries for your storage account service endpoints such that the endpoints for the secondary region become the new primary endpoints for your storage account. Once the failover is complete, clients can begin writing to the new primary endpoints.
+With globally redundant storage (GRS, GZRS, and RA-GZRS), Azure copies your data asynchronously to a secondary geographic region at least hundreds of miles away. This allows you to recover your data if there's an outage in the primary region. A feature that distinguishes globally redundant storage from LRS and ZRS is the ability to fail over to the secondary region if there's an outage in the primary region. The process of failing over updates the DNS entries for your storage account service endpoints such that the endpoints for the secondary region become the new primary endpoints for your storage account. Once the failover is complete, clients can begin writing to the new primary endpoints.
 
-RA-GRS and RA-GZRS redundancy configurations provide geo-redundant storage with the added benefit of read access to the secondary endpoint if there is an outage in the prinary region. If an outage occurs in the primary endpoint, applications configured for read access to the secondary region and designed for high availability can continue to read from the secondary endpoint. Microsoft recommends RA-GZRS for maximum availability and durability of your storage accounts.
+RA-GRS and RA-GZRS redundancy configurations provide geo-redundant storage with the added benefit of read access to the secondary endpoint if there is an outage in the primary region. If an outage occurs in the primary endpoint, applications configured for read access to the secondary region and designed for high availability can continue to read from the secondary endpoint. Microsoft recommends RA-GZRS for maximum availability and durability of your storage accounts.
 
 For more information about redundancy in Azure Storage, see [Azure Storage redundancy](storage-redundancy.md).
 

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

@@ -84,25 +84,25 @@ The following diagrams show what happens during customer-managed failover and fa
 
 Under normal circumstances, a client writes data to a storage account in the primary region via storage service endpoints (1). The data is then copied asynchronously from the primary region to the secondary region (2). The following image shows the normal state of a storage account configured as GRS when the primary endpoints are available:
 
-![Clients write data to the storage account in the primary region](media/storage-failover-customer-managed-common/pre-failover-grs.png)
+:::image type="content" source="media/storage-failover-customer-managed-common/pre-failover-grs.png" alt-text="Image showing how clients write data to the storage account in the primary region." lightbox="media/storage-failover-customer-managed-common/pre-failover-grs.png":::
 
 ### The storage service endpoints become unavailable in the primary region (GRS/RA-GRS)
 
 If the primary storage service endpoints become unavailable for any reason (1), the client is no longer able to write to the storage account. Depending on the underlying cause of the outage, replication to the secondary region may no longer be functioning (2), so [some data loss should be expected](storage-disaster-recovery-guidance.md#anticipate-data-loss-and-inconsistencies). The following image shows the scenario where the primary endpoints have become unavailable, but no recovery has occurred yet:
 
-![The primary is unavailable, so clients cannot write data](media/storage-failover-customer-managed-unplanned/primary-unavailable-before-failover-grs.png)
+:::image type="content" source="media/storage-failover-customer-managed-unplanned/primary-unavailable-before-failover-grs.png" alt-text="Image showing how the primary is unavailable, so clients cannot write data." lightbox="media/storage-failover-customer-managed-unplanned/primary-unavailable-before-failover-grs.png":::
 
 ### The failover process (GRS/RA-GRS)
 
 To restore write access to your data, you can [initiate a failover](storage-initiate-account-failover.md).  The storage service endpoint URIs for blobs, tables, queues, and files remain the same but their DNS entries are changed to point to the secondary region (1) as show in this image:
 
-![Customer initiates account failover to secondary endpoint](media/storage-failover-customer-managed-unplanned/failover-to-secondary-grs.png)
+:::image type="content" source="media/storage-failover-customer-managed-unplanned/failover-to-secondary-grs.png" alt-text="Image showing how the customer initiates account failover to secondary endpoint." lightbox="media/storage-failover-customer-managed-unplanned/failover-to-secondary-grs.png":::
 
 Customer-managed failover typically takes about an hour.
 
 After the failover is complete, the original secondary becomes the new primary (1) and the copy of the storage account in the original primary is deleted (2). The storage account is configured as LRS in the new primary region and is no longer geo-redundant. Users can resume writing data to the storage account (3) as shown in this image:
 
-![Storage account status post-failover to secondary region (GRS)](media/storage-failover-customer-managed-unplanned/post-failover-grs.png)
+:::image type="content" source="media/storage-failover-customer-managed-unplanned/post-failover-grs.png" alt-text="Image showing how the storage account status post-failover to secondary region." lightbox="media/storage-failover-customer-managed-unplanned/post-failover-grs.png":::
 
 To resume replication to a new secondary region, reconfigure the account for geo-redundancy.
 
@@ -111,7 +111,7 @@ To resume replication to a new secondary region, reconfigure the account for geo
 
 After re-configuring the account as GRS, Azure begins copying your data asynchronously to the new secondary region (1) as shown in this image:
 
-![Storage account status post-failover to secondary region as GRS (GRS)](media/storage-failover-customer-managed-unplanned/post-failover-grs-geo.png)
+:::image type="content" source="media/storage-failover-customer-managed-unplanned/post-failover-grs-geo.png" alt-text="Image showing how the storage account status post-failover to secondary region as GRS." lightbox="media/storage-failover-customer-managed-unplanned/post-failover-grs-geo.png":::
 
 Read access to the new secondary region will not become available again until the issue causing the original outage has been resolved.
 
@@ -128,11 +128,11 @@ Once the issue causing the original outage has been resolved, you can initiate a
 1. With customer-initiated failover and failback, your data is not allowed to finish replicating to the secondary region during the failback process. Therefore, it is important to check the value of the [**Last Sync Time**](last-sync-time-get.md) property before failing back.
 1. The DNS entries for the storage service endpoints are changed such that those for the secondary region become the new primary endpoints for your storage account.
 
-![Customer initiates account failback to original primary region (GRS)](media/storage-failover-customer-managed-unplanned/failback-to-primary-grs.png)
+:::image type="content" source="media/storage-failover-customer-managed-unplanned/failback-to-primary-grs.png" alt-text="Image showing how the customer initiates account failback to original primary region." lightbox="media/storage-failover-customer-managed-unplanned/failback-to-primary-grs.png":::
 
 After the failback is complete, the original primary region becomes the current one again (1) and the copy of the storage account in the original secondary is deleted (2). The storage account is configured as locally redundant in the primary region and is no longer geo-redundant. Users can resume writing data to the storage account (3) as shown in this image:
 
-![Post-failback status (GRS)](media/storage-failover-customer-managed-unplanned/post-failback-grs.png)
+:::image type="content" source="media/storage-failover-customer-managed-unplanned/post-failback-grs.png" alt-text="Image showing how Post-failback status." lightbox="media/storage-failover-customer-managed-unplanned/post-failback-grs.png":::
 
 To resume replication to the original secondary region, configure the account for geo-redundancy again.
 
@@ -141,33 +141,33 @@ To resume replication to the original secondary region, configure the account fo
 
 After re-configuring the account as GRS, replication to the original secondary region resumes as shown in this image:
 
-![The redundancy configuration returns to its original state](media/storage-failover-customer-managed-unplanned/post-failback-grs-geo.png)
+:::image type="content" source="media/storage-failover-customer-managed-unplanned/post-failback-grs-geo.png" alt-text="Image showing how the redundancy configuration returns to its original state." lightbox="media/storage-failover-customer-managed-unplanned/post-failback-grs-geo.png":::
 
 ## [GZRS/RA-GZRS](#tab/gzrs-ra-gzrs)
 
 ### Normal operation (GZRS/RA-GZRS)
 
 Under normal circumstances, a client writes data to a storage account in the primary region via storage service endpoints (1). The data is then copied asynchronously from the primary region to the secondary region (2). The following image shows the normal state of a storage account configured as GZRS when the primary endpoints are available:
 
-![Clients write data to the storage account in the primary region (GZRS)](media/storage-failover-customer-managed-common/pre-failover-gzrs.png)
+:::image type="content" source="media/storage-failover-customer-managed-common/pre-failover-gzrs.png" alt-text="Image showing how the clients write data to the storage account in the primary region." lightbox="media/storage-failover-customer-managed-common/pre-failover-gzrs.png":::
 
 ### The storage service endpoints become unavailable in the primary region (GZRS/RA-GZRS)
 
 If the primary storage service endpoints become unavailable for any reason (1), the client is no longer able to write to the storage account. Depending on the underlying cause of the outage, replication to the secondary region may no longer be functioning (2), [so some data loss should be expected](storage-disaster-recovery-guidance.md#anticipate-data-loss-and-inconsistencies). The following image shows the scenario where the primary endpoints have become unavailable, but no recovery has occurred yet:
 
-![The primary is unavailable, so clients cannot write data (GZRS)](media/storage-failover-customer-managed-unplanned/primary-unavailable-before-failover-gzrs.png)
+:::image type="content" source="media/storage-failover-customer-managed-unplanned/primary-unavailable-before-failover-gzrs.png" alt-text="Image showing how the primary is unavailable, so clients cannot write data." lightbox="media/storage-failover-customer-managed-unplanned/primary-unavailable-before-failover-gzrs.png":::
 
 ### The failover process (GZRS/RA-GZRS)
 
 To restore write access to your data, you can [initiate a failover](storage-initiate-account-failover.md).  The storage service endpoint URIs for blobs, tables, queues, and files remain the same but their DNS entries are changed to point to the secondary region (1) as show in this image:
 
-![Customer initiates account failover to secondary endpoint (GZRS)](media/storage-failover-customer-managed-unplanned/failover-to-secondary-gzrs.png)
+:::image type="content" source="media/storage-failover-customer-managed-unplanned/failover-to-secondary-gzrs.png" alt-text="Image showing how the customer initiates account failover to the secondary endpoint." lightbox="media/storage-failover-customer-managed-unplanned/failover-to-secondary-gzrs.png":::
 
 The failover typically takes about an hour.
 
 After the failover is complete, the original secondary becomes the new primary (1) and the copy of the storage account in the original primary is deleted (2). The storage account is configured as LRS in the new primary region and is no longer geo-redundant. Users can resume writing data to the storage account (3) as shown in this image:
 
-![Storage account status post-failover to secondary region (GZRS)](media/storage-failover-customer-managed-unplanned/post-failover-grs.png)
+:::image type="content" source="media/storage-failover-customer-managed-unplanned/post-failover-grs.png" alt-text="Image showing the storage account status post-failover to secondary region." lightbox="media/storage-failover-customer-managed-unplanned/post-failover-grs.png":::
 
 To resume replication to a new secondary region, reconfigure the account for geo-redundancy.
 
@@ -178,7 +178,7 @@ Since the account was originally configured as GZRS, reconfiguring geo-redundanc
 
 After re-configuring the account as GRS, Azure begins copying your data asynchronously to the new secondary region (1) as shown in this image:
 
-![Storage account status post-failover to secondary region as GRS (GZRS)](media/storage-failover-customer-managed-unplanned/post-failover-gzrs-geo.png)
+:::image type="content" source="media/storage-failover-customer-managed-unplanned/post-failover-gzrs-geo.png" alt-text="Image showing the storage account status post-failover to secondary region as GRS." lightbox="media/storage-failover-customer-managed-unplanned/post-failover-gzrs-geo.png":::
 
 Read access to the new secondary region will not become available again until the issue causing the original outage has been resolved.
 
@@ -195,11 +195,11 @@ Once the issue causing the original outage has been resolved, you can initiate a
 1. With customer-initiated failover and failback, your data is not allowed to finish replicating to the secondary region during the failback process. Therefore, it is important to check the value of the [**Last Sync Time**](last-sync-time-get.md) property before failing back.
 1. The DNS entries for the storage service endpoints are changed such that those for the secondary region become the new primary endpoints for your storage account.
 
-![Customer initiates account failback to original primary region (GZRS)](media/storage-failover-customer-managed-unplanned/failback-to-primary-gzrs.png)
+:::image type="content" source="media/storage-failover-customer-managed-unplanned/failback-to-primary-gzrs.png" alt-text="Image showing the customer initiates account failback to original primary region." lightbox="media/storage-failover-customer-managed-unplanned/failback-to-primary-gzrs.png":::
 
 After the failback is complete, the original primary region becomes the current one again (1) and the copy of the storage account in the original secondary is deleted (2). The storage account is configured as ZRS in the primary region and is no longer geo-redundant. Users can resume writing data to the storage account (3) as shown in this image:
 
-![Post-failback status (GZRS)](media/storage-failover-customer-managed-unplanned/post-failback-gzrs.png)
+:::image type="content" source="media/storage-failover-customer-managed-unplanned/post-failback-gzrs.png" alt-text="Image showing the post-failback status." lightbox="media/storage-failover-customer-managed-unplanned/post-failback-gzrs.png":::
 
 To resume replication to the original secondary region, configure the account for geo-redundancy again.
 
@@ -208,7 +208,7 @@ To resume replication to the original secondary region, configure the account fo
 
 After re-configuring the account as GZRS, replication to the original secondary region resumes as shown in this image:
 
-![The redundancy configuration returns to its original state](media/storage-failover-customer-managed-unplanned/post-failback-gzrs-geo.png)
+:::image type="content" source="media/storage-failover-customer-managed-unplanned/post-failback-gzrs-geo.png" alt-text="Image showing the redundancy configuration returns to its original state." lightbox="media/storage-failover-customer-managed-unplanned/post-failback-gzrs-geo.png":::
 
 ---