minor changes

AbhishekMallick-MS · AbhishekMallick-MS · commit 6c6b8eb51d84 · 2021-10-08T11:31:27.000+05:30
diff --git a/articles/backup/backup-afs.md b/articles/backup/backup-afs.md
@@ -2,7 +2,7 @@
 title: Back up Azure file shares in the Azure portal
 description: Learn how to use the Azure portal to back up Azure file shares in the Recovery Services vault
 ms.topic: conceptual
-ms.date: 10/07/2021
+ms.date: 10/08/2021
 ---
 
 # Back up Azure file shares
diff --git a/articles/backup/backup-azure-files-faq.yml b/articles/backup/backup-azure-files-faq.yml
@@ -2,7 +2,7 @@
 metadata:
   title: Back up Azure Files FAQ
   description: In this article, discover answers to common questions about how to protect your Azure file shares with the Azure Backup service.
-  ms.date: 04/22/2020
+  ms.date: 10/08/2021
   ms.topic: article
   ms.service: backup
     
@@ -39,7 +39,7 @@ sections:
       - question: |
           Why can't I change the vault to configure backup for the file share?
         answer: |
-          If the storage account is already registered with a vault or other file shares in the storage account are protected using a vault , you aren't given an option to change it. All file shares in a storage account can be protected only by the same vault. If you want to change the vault, you'll need to [stop protection for all file shares in the storage account](manage-afs-backup.md#stop-protection-on-a-file-share) from the connected vault, [unregister](manage-afs-backup.md#unregister-a-storage-account) the Storage Account, and then choose a different vault for protection.
+          If the storage account is already registered with a vault or other file shares in the storage account are protected using a vault, you aren't given an option to change it. All file shares in a storage account can be protected only by the same vault. If you want to change the vault, you'll need to [stop protection for all file shares in the storage account](manage-afs-backup.md#stop-protection-on-a-file-share) from the connected vault, [unregister](manage-afs-backup.md#unregister-a-storage-account) the Storage Account, and then choose a different vault for protection.
           
       - question: |
           Can I change the Vault to which I back up my file shares?
@@ -85,15 +85,15 @@ sections:
       - question: |
           Why Azure Files backups doesn't replicate based on the Storage Replication Type setting of the vault?
         answer: |
-          The Storage Replication setting of the vault isn't relevant for Azure Files backup. This is because the current solution is snapshot based and there's no data transferred to the vault. Snapshots are stored in the same storage account as the backed-up file share, and therefore replicated as per the replication setting of storage account.
+          The Storage Replication setting of the vault isn't relevant for Azure Files backup. This is because the current solution is snapshot-based and there's no data transferred to the vault. Snapshots are stored in the same storage account as the backed-up file share, and therefore replicated as per the replication setting of storage account.
           
       - question: |
           Can I access the snapshots taken by Azure Backups and mount them?
         answer: |
           All snapshots taken by Azure Backup can be accessed by viewing snapshots in the portal, PowerShell, or CLI. To learn more about Azure Files share snapshots, see [Overview of share snapshots for Azure Files](../storage/files/storage-snapshots-files.md).
           
       - question: |
-          What happens after I move a backed up file share to a different subscription?
+          What happens after I move a backed-up file share to a different subscription?
         answer: |
           Once a file share is moved to a different subscription, it's considered as a new file share by Azure Backup. These are the recommended steps:
            
@@ -107,9 +107,9 @@ sections:
           Note that after reconfiguring backup with V2, the snapshots that were taken with V1 will no longer be managed by Azure Backup. So you'll have to delete those snapshots manually according to your requirements.
           
       - question: |
-          Can I move my backed up file share to a different resource group?
+          Can I move my backed-up file share to a different resource group?
         answer: |
-          Yes, you can move your backed up file share to a different resource group. However, you'll need to reconfigure backup for the file share as it will be treated as a new resource by Azure Backup. Also, the snapshots that were created before the resource group move will no longer be managed by Azure backup. So you'll have to delete those snapshots manually according to your requirements.
+          Yes, you can move your backed-up file share to a different resource group. However, you'll need to reconfigure backup for the file share as it will be treated as a new resource by Azure Backup. Also, the snapshots that were created before the resource group move will no longer be managed by Azure backup. So you'll have to delete those snapshots manually according to your requirements.
 
       - question: |
           What is the maximum retention I can configure for backups?
@@ -161,7 +161,7 @@ sections:
       - question: |
           What is the impact on existing recovery points when I modify an existing GFS Policy?
         answer: |
-          When a new policy is applied on file shares, all the future scheduled backups will be taken according to the schedule configured in the modified policy.  The retention of all existing recovery points is aligned according to the new retention values configured. So if the retention is extended, existing recovery points are marked to be retained according to the new policy. If the retention is reduced, they're marked for clean-up in the next cleanup job and then deleted.
+          When a new policy is applied on file shares, all the future scheduled backups will be taken according to the schedule configured in the modified policy.  The retention of all existing recovery points is aligned according to the new retention values configured. So, if the retention is extended, existing recovery points are marked to be retained according to the new policy. If the retention is reduced, they're marked for clean-up in the next cleanup job and then deleted.
           
           Here's an example of how this works:
           
@@ -198,7 +198,7 @@ sections:
         answer: |
           The **duration** attribute helps to determine the timestamp for last backup of the day. 
 
-          For example, if the **start time** is “x am” and **duration** is “y hours”, the backups will be scheduled between “x am” and based on the **schedule** attribute (x am + y hours) defined in the policy. This attribute enables you to ensure backups are only triggered during your working hours when there are frequent update operations on file share contents; therefore, taking multiple snapshots will safeguard data from any accidental changes.
+          For example, if the **start time** is “x AM” and **duration** is “y hours”, the backups will be scheduled between “x AM” and based on the **schedule** attribute (x AM + y hours) defined in the policy. This attribute enables you to ensure backups are only triggered during your working hours when there're frequent update operations on file share contents; therefore, taking multiple snapshots will safeguard data from any accidental changes.
 
       - question: |
           How are the backups scheduled based on the attributes - start time, schedule, and duration?
@@ -209,18 +209,18 @@ sections:
           - **Schedule**: Every 6 hours
           - **Duration**: 12 hours
 
-          Based on these values, the backup window is calculated as 9 am – 9 am + 12 hours, that is, 9 am – 9 pm. Therefore, all backups will be scheduled within this window.
+          Based on these values, the backup window is calculated as 9 AM – 9 AM + 12 hours, that is, 9 AM – 9 PM. Therefore, all backups will be scheduled within this window.
 
-          The first backup of the day is triggered at the start time mentioned in the policy, that is, 9 am, and the schedule determines the time difference between consecutive backups, that is, 6 hours. With this calculation, your backup schedule would be: 9 am, 1 pm (9 am + 6 hours), 5 pm (1 pm + 6 hours), and 9 pm (5 pm + 6 hours).
+          The first backup of the day is triggered at the start time mentioned in the policy, that is, 9 AM, and the schedule determines the time difference between consecutive backups, that is, 6 hours. With this calculation, your backup schedule would be: 9 AM, 1 PM (9 AM + 6 hours), 5 PM (1 PM + 6 hours), and 9 PM (5 PM + 6 hours).
 
-          Since, the end time of backup window that we calculated was 9 PM, no backup would be triggered after this time.
+          Since, the end time of backup window we calculated was 9 PM, no backup would be triggered after this time.
 
       - question: |
-          Why am I getting the error “The selected configuration will trigger only 1 backup per day” ?
+          Why am I getting the error “The selected configuration will trigger only 1 backup per day”?
         answer: |
-          This error would occur if you specified a schedule that is greater than the duration. For example, you've configured **start time** as 9 am, **schedule** as 6 hours, and **duration** as 4 hours. In this case, the only time when backup job can trigger is 9 am, since the next backup time of 3 PM (9am + 6 hours) is outside the backup window: 9 am – 1 pm ( 9 am + 4 hours). 
+          This error would occur if you specified a **schedule** that's greater than the **duration**. For example, you've configured **start time** as 9 AM, **schedule** as 6 hours, and **duration** as 4 hours. In this scenario, the only time when backup job can trigger is 9 AM, since the next backup time of 3 PM (9 AM + 6 hours) is outside the backup window: 9 AM – 1 PM (9 AM + 4 hours).
 
-          To fix this, we recommend you adjust your schedule or duration, or select **Daily** frequency rather than **Hourly**.
+          To fix this, we recommend you adjust your schedule or duration, or select **Daily** frequency instead of **Hourly**.
 
       - question: |
           Why am I getting the error “The selected configuration extends backup window to next day”?
@@ -229,23 +229,25 @@ sections:
 
           For example, you configured a policy with the following parameters:
 
-          - **Schedule**: Every 4 hours.
-          - **Start time**: 12 pm
+          - **Schedule**: Every 4 hours
+          - **Start time**: 12 PM
           - **Duration**: 15 hours
 
-          Based on this configuration, the backup window will be: 12 pm – 3 am (12 pm +15 hours). Since, the start and end time are falling on two different days, we recommend you adjust the start time or duration to ensure they are on the same day.
+          Based on this configuration, the backup window will be: 12 PM – 3 AM (12 PM + 15 hours). Since, the start and end time are falling on two different days, we recommend you adjust the **start time** or **duration** to ensure they are on the same day.
 
       - question: |
           What’s the impact on the existing recovery points when I switch from “Daily” to “Hourly” frequency?
         answer: |
-          When you switch from “Daily” to “Hourly” frequency, the behavior is as follows:
+          When you switch from **Daily** to **Hourly** frequency, the behavior is as follows:
 
           - **Retention**: If you're adding weekly/monthly/yearly retention as part of modifying the policy, all the future recovery points created as part of the scheduled backup will be tagged according to the new policy. All the existing recovery points will still be considered as daily recovery points; so, they won’t be tagged as weekly/monthly/yearly.
 
           - **Snapshots and recovery points cleanup**:
+
             - If daily retention is extended, the expiration date of the existing daily recovery points is updated according to the daily retention value configured in the new policy.
-            - If daily retention is reduced, the existing daily recovery points and snapshots are marked for deletion in the next cleanup run job according to the daily retention value configured in the new policy and then deleted.
-          Let’s assume, you change the start time to 6 AM in the above configuration. Now, the backup window will be 6 am – 9 pm (6 am + 15 hours). This is a supported configuration.
+            - If daily retention is reduced, the existing daily recovery points and snapshots are marked for deletion in the next cleanup run job according to the daily retention value configured in the new policy, and then deleted.
+
+          Let’s assume, you change the start time to 6 AM in the above configuration. Now, the backup window will be 6 AM – 9 PM (6 AM + 15 hours). This is a supported configuration.
 
 additionalContent: |
 
diff --git a/articles/backup/manage-afs-backup.md b/articles/backup/manage-afs-backup.md
@@ -2,7 +2,7 @@
 title: Manage Azure file share backups
 description: This article describes common tasks for managing and monitoring the Azure file shares that are backed up by Azure Backup.
 ms.topic: conceptual
-ms.date: 10/07/2021
+ms.date: 10/08/2021
 ---
 
 # Manage Azure file share backups
@@ -35,7 +35,7 @@ To create a new backup policy, follow these steps:
 
 1. In the **Backup policies** pane of the Recovery Services vault, select **+ Add**.
 
-   ![New backup policy](./media/manage-afs-backup/new-backup-policy.png)
+   :::image type="content" source="./media/manage-afs-backup/new-backup-policy.png" alt-text="Screenshot showing the option to start creating a new backup policy.":::
 
 1. In the **Add** pane, select **Azure File Share** as the **Policy Type**.
 
@@ -62,7 +62,7 @@ To create a new backup policy, follow these steps:
      For example, you’ve the RPO (recovery point objective) requirement of 4 hours and your working hours are 9 AM to 9 PM. To meet these requirements, the configuration for backup schedule would be:
     
      - Schedule: Every 4 hours
-     - Start time: 9 am 
+     - Start time: 9 AM 
      - Duration: 12 hours 
      
      :::image type="content" source="./media/manage-afs-backup/hourly-backup-frequency-values-scenario.png" alt-text="Screenshot showing an example of hourly backup frequency values.":::
