Added default policy, MDCC and ILR failure updates

Author: akarshprabhu

articles/backup/backup-azure-manage-vms.md

@@ -86,6 +86,11 @@ To manage a backup policy:
 
     :::image type="content" source="./media/backup-azure-manage-vms/backup-policy-create-new-inline.png" alt-text="Screenshot showing to choose a backup policy." lightbox="./media/backup-azure-manage-vms/backup-policy-create-new-expanded.png":::
 
+### Default backup policies in Recovery Services vaults
+When you create a Recovery Services vault, Azure Backup automatically creates a small set of system‑managed default backup policies. These policies ensure that baseline backup functionality is always available in any vault. Examples include policies such as HourlyBackup, DefaultPolicy, or Enhanced.
+These default policies are system‑managed, can be deleted temporarily but are recreated automatically and act as fallback policies when no custom policy is defined.
+You can safely ignore these default policies if your organization uses its own standards for policy naming, scheduling, or retention. Create custom backup policies that match your requirements and assign your protected items to those custom policies. The default policies will continue to exist in the vault but will not be used unless explicitly selected.
+
 ## Run an on-demand backup
 
 You can run an on-demand backup of a VM after you set up its protection. Keep these details in mind:

articles/backup/backup-azure-vm-backup-faq.yml

@@ -184,16 +184,17 @@ sections:
           
           **When the checkbox is NOT selected:**
           
-          Enhanced Policy will attempt to take application-consistent or filesystem-consistent backups. However, if these attempts fail, the policy will fall back to crash-consistent backups at specific intervals:
+          Enhanced Policy will attempt to take application-consistent or filesystem-consistent backups. However, if these attempts fail, the policy will fallback to crash-consistent backups at specific intervals:
             - A crash-consistent snapshot will be taken on the 4th, 6th, and 8th attempt.
             - This fallback ensures backup continuity even when consistency cannot be guaranteed.
-          
+          Reasons for fallback to MDCC include offline VMs, VMs with unsupported OS, Guest Agent issues, VMSnapshotLinux extension provisioning issues etc.   
+
           **When the checkbox is selected:**
 
           The policy will not attempt application or filesystem consistency. Instead, it will directly initiate a crash-consistent MDCC backup without any retries for higher consistency levels.
           
           This option is useful when speed and simplicity are prioritized over consistency guarantees.
-      - question: When we migrate the policy from the Standard to enhanced, how does the retention period will apply on the restore points?
+      - question: When we migrate a protected item from the Standard to Enhanced policy, which retention period  applies on the restore points?
         answer: |
           Retention Period will apply as per the new enhanced policy for all the restore points.
       - question: Why don’t I see the updated expiry time for my Recovery Points immediately after changing the backup policy?

articles/backup/backup-azure-vm-file-recovery-troubleshoot.md

@@ -166,16 +166,25 @@ To identify and resolve this issue, perform the following steps:
 
 >[!Tip]
 >Ensure you have the [right machine to run the script](./backup-azure-restore-files-from-vm.md#step-2-ensure-the-machine-meets-the-requirements-before-executing-the-script).
-
 If the protected Linux VM uses LVM or RAID Arrays, follow the steps in [Recover files from Azure virtual machine backup](./backup-azure-restore-files-from-vm.md#lvmraid-arrays-for-linux-vms).
 
+##### Disks are attached but volumes aren’t mounted on Linux VMs when multipath is enabled
+
+**Possible cause:**
+When you run Individual File Recovery (ILR) on a Linux VM, Azure Backup attaches the recovery disks to the VM using iSCSI. If multipath is enabled on the VM, the Linux OS might identify these iSCSI disks as multipath devices and claim them through the multipath daemon. As a result, the disks aren’t mounted as regular block devices during file recovery.
+This issue is commonly observed on Linux distributions where multipath is enabled by default.
+
+**Recommended action:**
+Update the multipath configuration on the VM to exclude iSCSI devices used for file recovery from multipath handling. After applying the configuration change and restarting the multipath service, rerun the file recovery script. For guidance on configuring multipath exclusions, refer to the documentation for your Linux distribution. 
+<br/> Ubuntu: [Multipath configuration options and overview](https://documentation.ubuntu.com/server/explanation/multipath/configuring-multipath/)
+
 ### You can't copy the files from mounted volumes
 
 The copy might fail with the error **0x80070780: The file cannot be accessed by the system.**
 
 Check if the source server has disk **deduplication** enabled. If the option is enabled, ensure the restore server also has **deduplication** enabled on the drives. You can leave deduplication unconfigured so that you don't deduplicate the drives on the restore server.
 
-### Disk is not unmount although clicked Unmount disks on Azure Portal (Linux OS)
+### Disk is not unmounted although Unmount disks is clicked on Azure Portal (Linux OS)
 
 Unmount disks manually by running python script with the `clean` parameter. The following example shows installation of **python 3 package** by the machine.