Merge pull request #308784 from MicrosoftDocs/main

Auto Publish – main to live - 2025-11-26 12:00 UTC

Author: learn-build-service-prod[bot]

articles/backup/azure-data-lake-storage-backup-support-matrix.md

@@ -37,7 +37,7 @@ The following table lists the supported storage account details:
 | ------------------------ | ------------------------------------------------------------ |
 | Account  Kind            | Only block blobs in a standard general-purpose v2 HNS-enabled storage account. <br><br>*Accounts using Network File Shares (NFS) 3.0, and Secure File Transfer Protocol (SFTP) protocols for blobs are currently not supported*.|
 | Redundancy              | Locally redundant storage (LRS), Zone-redundant storage (ZRS), Geo-redundant storage (GRS) enabled storage account. |
-| Tier              | Hot, Cool, and Cold tier blobs are supported.<br><br>*Archive tier blob backup isn't supported*. |
+| Tier              | Hot, Cool, and Cold tier blobs are supported.<br><br>*Backup for the Archive tier blob in Azure Data Lake storage account isn't supported*. |
 | Upgraded storage accounts              | Accounts upgraded from Azure Blob Storage to Azure Data Lake Storage aren't supported*. |
 
 ## Protection limits
@@ -49,31 +49,35 @@ The following table lists the protection limits:
 | Maximum number of containers in a storage account that can be protected | 100 |
 | Vault redundancy              | LRS/ZRS/GRS |
 
-### Supported and unsupported scenarios for Azure Data Lake Storage protection
+### Supported scenarios for Azure Data Lake Storage protection
 
-Azure Data Lake Storage protection has the following supported and unsupported scenarios:
+Azure Data Lake Storage protection has the following supported scenarios:
+
+- Backup vaults with System-Assigned Managed Identity (SAMI) works for backup, because the vault needs to access the storage account where the blobs are stored. The vault uses its system-assigned managed identity for this access.
+- You can protect the storage account with the vault in another subscription but in the same region as storage account.
+- Azure Data Lake Storage accounts support both Blob and Data File System (DFS) APIs.
+- `$web` container can't be restored as `$web` on the target. Use the **renameTo** option and restore it with a different container name.
+- `$root` container can be restored as `$root` on the target only if `$root` doesn't already exist there. If it already exists, use the **renameTo** option and restore it with a different container name. 
+
+### Unsupported scenarios and considerations for Azure Data Lake Storage protection
+
+Azure Data Lake Storage protection has the following unsupported scenarios:
 
 - Any new containers that get created after backup configuration for the storage account aren't backed up automatically. To enable the backup operation for the new containers, modify the protection of the storage account. 
 - The storage accounts to be backed up must contain a *minimum of one container*. If the storage account doesn't contain any containers or if no containers are selected, an error might appear when you configure backup.
-- Object Replication fails to register changes when a storage account or container is deleted and recreated with the same name between two consecutive backups, causing recovery points to retain older blobs and versions.
-- Blobs are excluded from recovery points if you rename any folder in their parent path when async copy in progress.
-- The backup operation isn't supported for blobs created using async copy. 
-- Backup vaults with User-Assigned Managed Identity (UAMI) aren't compatible with Azure Blob Vaulted backups. Only System-Assigned Managed Identity (SAMI) works, because the vault needs to access the storage account where the blobs are stored. The vault uses its system-assigned managed identity for this access.
-- You can protect the storage account with the vault in another subscription but in the same region as storage account.
-- Archive tier for vault is currently not supported.
-- Azure Data Lake Storage accounts support both Blob and Data File System (DFS) APIs. The system captures operations through Change Feed and uses directory snapshots to ensure consistent recovery.
+- Backup vaults with User-Assigned Managed Identity (UAMI) aren't compatible with Azure Blob Vaulted backups.
+- When an Azure Data Lake Storage account or container in it is deleted and recreated with the same name between two consecutive backups, then recovery points retain older blobs and versions.
+- Archive tier for the backup data in a vault is currently not supported.
+- Storage accounts upgraded from FNS to HNS are not supported for backup.
+- SFTP- and NFS-enabled accounts aren’t supported for Vaulted Backup. Backup jobs on these accounts fail or hang when processing blobs uploaded via SFTP.
 - Vaulted Backup doesn’t support cross-container data moves because backup policies are container-specific. If you move data between containers, the replication consistency breaks.
-- When blob expiry is configured—either during creation using PutBlob or PutBlockList, or later via the SetBlobExpiry API — the following behaviors apply for storage accounts with Vaulted Backup enabled:
+- When blob in Data Lake Storage accounts have expiry configured—either during creation using PutBlob or PutBlockList, or later via the SetBlobExpiry API — the following behaviors apply for Azure Data Lake storage account with Vaulted Backup enabled:
   - Existing Blobs with Expiry Date: These blobs will continue to exhibit the current behavior: once expired, they remain in existing restore points, which can lead to inconsistencies in future restore points.
   - Future Expiry Settings: Any attempt to set expiry using SetBlobExpiry will fail for storage accounts configured with Vaulted Backup. This restriction ensures restore point integrity going forward.
 - When Vaulted Backup is enabled:
-  - Soft Delete: Objects can still be soft-deleted as expected.
-  - Undelete: Restore from soft-deleted state is not supported while Vaulted Backup is active. Undelete will only work if Vaulted Backup is disabled first. Re-enabling Vaulted Backup after disabling will trigger a full backup.
-- Storage accounts upgraded from FNS to HNS are not supported for backup.
-- SFTP- and NFS-enabled accounts aren’t supported for Vaulted Backup. Backup jobs on these accounts fail or hang when processing blobs uploaded via SFTP.
-- $web container cannot be restored as $web on the target. Use the renameTo option and restore it with a different container name.
-- $root container can be restored as $root on the target only if $root does not already exist there. If it already exists, use the renameTo option and restore it with a different container name.
-
+  - Soft Delete: Blobs in Azure Data Lake storage account can still be soft-deleted as expected.
+  - Undelete: Restore for blobs in Azure Data Lake storage account from soft-deleted state is not supported while Vaulted Backup is active. Undelete will only work if Vaulted Backup is disabled first. Re-enabling Vaulted Backup after disabling will trigger a full backup.
+  
 ## Backup limits
 
 The following table lists the Backup limits:

articles/backup/backup-azure-monitoring-use-azuremonitor.md

@@ -2,7 +2,7 @@
 title: Azure Monitor Logs in Azure Backup
 description: Monitor Azure Backup workloads and create custom alerts by using Azure Monitor.
 ms.topic: how-to
-ms.date: 12/30/2024
+ms.date: 11/26/2025
 ms.assetid: 01169af5-7eb0-4cb0-bbdb-c58ac71bf48b
 author: AbhishekMallick-MS
 ms.author: v-mallicka
@@ -14,14 +14,14 @@ ms.custom:
 
 # Azure Monitor Logs
 
-Azure Backup provides [built-in monitoring and alerting capabilities](backup-azure-monitoring-built-in-monitor.md) in a Recovery Services vault. These capabilities are available without any additional management infrastructure. The only pre-requisite for this capability is to have Log Analytics workspace configured. This feature is supported in the following scenarios:
+Azure Backup provides [built-in monitoring and alerting capabilities](backup-azure-monitoring-built-in-monitor.md) in a Recovery Services vault. These capabilities are available without any extra management infrastructure. The only prerequisite for this capability is to have Log Analytics workspace configured. This feature is supported in the following scenarios:
 
 - Monitoring data from multiple Recovery Services vaults across Subscriptions
 - Visibility into custom scenarios
 - Configuring alerts for custom scenarios
-- Viewing information from an on-premises component.  For example, System Center Data Protection Manager information  in Azure, which the portal doesn't show in [**Backup Jobs**](backup-azure-monitoring-built-in-monitor.md#backup-jobs) or [**Backup Alerts**](move-to-azure-monitor-alerts.md#backup-alerts-in-recovery-services-vault)
+- Viewing information from an on-premises component. For example, System Center Data Protection Manager information  in Azure, which the portal doesn't show in [**Backup Jobs**](backup-azure-monitoring-built-in-monitor.md#backup-jobs) or [**Backup Alerts**](move-to-azure-monitor-alerts.md#backup-alerts-in-recovery-services-vault)
 
-## Using Log Analytics workspace
+## Monitor backup jobs using Log Analytics workspace
 
 ### Prerequisites for using Log Analytics workspace
 
@@ -42,7 +42,7 @@ Open the **Logs** section of the Log Analytics workspace and create a query for
 
 ![Create an alert in a Log Analytics workspace](media/backup-azure-monitoring-laworkspace/custom-alert.png)
 
-Here the resource is already marked as the Log Analytics workspace, and action group integration is provided.
+Here, the resource is already marked as the Log Analytics workspace, and action group integration is provided.
 
 ![The Log Analytics alert-creation page](media/backup-azure-monitoring-laworkspace/inkedla-azurebackup-createalert.jpg)
 
@@ -52,7 +52,7 @@ The defining characteristic of an alert is its triggering condition. Select **Co
 
 ![Setting up an alert condition](media/backup-azure-monitoring-laworkspace/la-azurebackup-alertlogic.png)
 
-If necessary, you can edit the Kusto query. Choose a threshold, period, and frequency. The threshold determines when the alert will be raised. The period is the window of time in which the query is run. For example, if the threshold is greater than 0, the period is 5 minutes, and the frequency is 5 minutes, then the rule runs the query every 5 minutes, reviewing the previous 5 minutes. If the number of results is greater than 0, you're notified through the selected action group.
+If necessary, you can edit the Kusto query. Choose a threshold, period, and frequency. The threshold determines when the alert is raised. The period is the window of time in which the query is run. For example, if the threshold is greater than 0, the period is 5 minutes, and the frequency is 5 minutes, then the rule runs the query every 5 minutes, reviewing the previous 5 minutes. If the number of results is greater than 0, you're notified through the selected action group.
 
 > [!NOTE]
 > To run the alert rule once a day, across all the events/logs that were created on the given day, change the value of both 'period' and 'frequency' to 1440, that is, 24 hours.
@@ -71,7 +71,7 @@ For more information, see [Create, view, and manage log alerts by using Azure Mo
 
 The default graphs give you Kusto queries for basic scenarios on which you can build alerts. You can also modify the queries to fetch the data you want to be alerted on. Paste the following sample Kusto queries on the **Logs** page, and then create alerts on the queries.
 
-Recovery Services vaults and Backup vaults send data to a common set of tables that are listed in this article. However, there are slight differences in the schema for Recovery Services vaults and Backup vaults ([learn more](backup-azure-monitoring-built-in-monitor.md)). So, this section is split into multiple sub-sections that helps you to use the right queries depending on which workload or vault types you want to query.
+Recovery Services vaults and Backup vaults send data to a common set of tables that are listed in this article. However, there are slight differences in the schema for Recovery Services vaults and Backup vaults ([learn more](backup-azure-monitoring-built-in-monitor.md)). So, this section is split into multiple subsections that helps you to use the right queries depending on which workload or vault types you want to query.
 
 #### Queries common across Recovery Services vaults and Backup vaults 
 
@@ -95,7 +95,7 @@ Recovery Services vaults and Backup vaults send data to a common set of tables t
 
 #### Queries specific to Recovery Services vault workloads
 
-- All successful Azure VM backup jobs
+- All successful Azure Virtual Machine (VM) backup jobs
 
     ````Kusto
     AddonAzureBackupJobs
@@ -198,7 +198,7 @@ Recovery Services vaults and Backup vaults send data to a common set of tables t
 
 ### Diagnostic data update frequency
 
-The diagnostic data from the vault is pumped to the Log Analytics workspace with some lag. Every event arrives at the Log Analytics workspace *20 to 30 minutes* after it's pushed from the Recovery Services vault. Here are further details about the lag:
+The diagnostic data from the vault is pumped to the Log Analytics workspace with some lag. Every event arrives at the Log Analytics workspace *20 to 30 minutes* after being pushed from the Recovery Services vault. Here are further details about the lag:
 
 - Across all solutions, the backup service's built-in alerts are pushed as soon as they're created. So they usually appear in the Log Analytics workspace after 20 to 30 minutes.
 - Across all solutions, on-demand backup jobs and restore jobs are pushed as soon as they *finish*.
@@ -210,7 +210,7 @@ The diagnostic data from the vault is pumped to the Log Analytics workspace with
 > [!NOTE]
 > The same delay applies to other destinations for diagnostics data, such as Storage accounts and Event Hubs.
 
-## Using the Recovery Services vault's activity logs
+## Monitor backup jobs using the Recovery Services vault's activity logs
 
 > [!CAUTION]
 > The following steps apply only to *Azure VM backups.* You can't use these steps for solutions such as the Azure Backup agent, SQL backups within Azure, or Azure Files.
@@ -233,11 +233,11 @@ To identify the appropriate log and create an alert:
 
    ![New alert rule](media/backup-azure-monitoring-laworkspace/new-alert-rule.png)
 
-Here the resource is the Recovery Services vault itself. Repeat the same steps for all of the vaults in which you want to be notified through activity logs. The condition won't have a threshold, period, or frequency because this alert is based on events. As soon as the relevant activity log is generated, the alert is raised.
+Here, the resource is the Recovery Services vault itself. Repeat the same steps for all of the vaults in which you want to be notified through activity logs. The condition doesn't have a threshold, period, or frequency because this alert is based on events. As soon as the relevant activity log is generated, the alert is raised.
 
-## Using Log Analytics to monitor at scale
+## Monitor at scale using Log Analytics workspace
 
-You can view all alerts created from activity logs and Log Analytics workspaces in Azure Monitor. Just open the **Alerts** pane on the left.
+You can view all alerts created from activity logs and Log Analytics workspaces in Azure Monitor. Just open the **Alerts** pane.
 
 Although you can get notifications through activity logs, we highly recommend using Log Analytics rather than activity logs for monitoring at scale. Here's why:
 

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

@@ -2,7 +2,7 @@
 title: Back up and recover Azure VMs with PowerShell
 description: Describes how to back up and recover Azure VMs using Azure Backup with PowerShell
 ms.topic: how-to
-ms.date: 12/03/2024
+ms.date: 11/26/2025
 ms.custom: devx-track-azurepowershell, engagement-fy24
 ms.service: azure-backup
 author: AbhishekMallick-MS
@@ -32,7 +32,7 @@ The object hierarchy is summarized in the following diagram.
 
 Review the **Az.RecoveryServices** [cmdlet reference](/powershell/module/az.recoveryservices/) reference in the Azure library.
 
-## Set up and register
+## Set up Azure PowerShell for Azure VM backup
 
 [!INCLUDE [updated-for-az](~/reusable-content/ce-skilling/azure/includes/updated-for-az.md)]
 
@@ -75,7 +75,7 @@ To begin:
 
     In the command output, the **RegistrationState** should change to **Registered**. If not, just run the **[Register-AzResourceProvider](/powershell/module/az.resources/register-azresourceprovider)** cmdlet again.
 
-## Create a Recovery Services vault
+## Create a Recovery Services vault for Azure VM backup
 
 The following steps lead you through creating a Recovery Services vault. A Recovery Services vault is different than a Backup vault.
 
@@ -256,7 +256,7 @@ Enable-AzRecoveryServicesBackupProtection -Policy $pol -Name "V2VM" -ResourceGro
 
 If you want to selectively back up a few disks and exclude others as mentioned in [these scenarios](selective-disk-backup-restore.md#scenarios), you can configure protection and backup only the relevant disks as documented [here](selective-disk-backup-restore.md#enable-backup-with-powershell).
 
-## Monitoring a backup job
+## Monitor an Azure VM backup job
 
 You can monitor long-running operations, such as backup jobs, without using the Azure portal. To get the status of an in-progress job, use the [Get-AzRecoveryservicesBackupJob](/powershell/module/az.recoveryservices/get-azrecoveryservicesbackupjob) cmdlet. This cmdlet gets the backup jobs for a specific vault, and that vault is specified in the vault context. The following example gets the status of an in-progress job as an array, and stores the status in the $joblist variable.