Merge branch 'main' into release-durable-task

Author: v-alje

articles/app-service/manage-backup.md

@@ -120,6 +120,9 @@ There are two types of backups in App Service. If your app is in a supported pri
 1. At the top of the **Backups** page, select **Configure custom backups**.
 
 1. In **Storage account**, select an existing storage account in the same subscription or select **Create new**. Repeat in **Container**.
+    > [!NOTE]
+    > Custom backups for Azure App Service require an Azure Storage account that supports Shared Access Signature (SAS)–based authorization. Managed Identity–based authentication to the storage account isn't supported for App Service backup and restore operations.
+   
 
     To back up the linked databases, select **Next: Advanced** > **Include database**, and select the databases to backup.
 

articles/azure-resource-manager/management/request-limits-and-throttling.md

@@ -18,7 +18,7 @@ The token bucket represents the maximum number of requests that you can send for
 
 These updated limits make it easier for you to refresh and manage your quota.
 
-The updated limits are:
+The updated limits for public and sovereign clouds are:
 
 | Scope | Operations | Bucket size | Refill rate per sec |
 | ----- | ---------- | ----------- | ------------------- |
@@ -37,8 +37,6 @@ For example, suppose you have a bucket size of 250 tokens for read requests and
 
 Reading metrics using the `*/providers/microsoft.insights/metrics` API contributes significantly to overall Azure Resource Manager traffic and is a common cause of subscription throttling events. If you use this API heavily, we recommend that you switch to the `getBatch` API. You can query multiple resources in a single REST request, which improves performance and reduces throttling. For more information about converting your operations, see [How to migrate from the metrics API to the getBatch API](/azure/azure-monitor/essentials/migrate-to-batch-api).
 
-These limits and architecture will also apply to all sovereign clouds by the end of 2026.
-
 ### How can I view my throttled requests?
 
 To view your throttled requests and other Resource Manager metrics, see [Accessing Azure Resource Manager metrics](/azure/azure-resource-manager/management/monitor-resource-manager#accessing-azure-resource-manager-metrics).
@@ -63,39 +61,6 @@ The request for subscription '{0}' could not be processed due to an excessive vo
 
 Customers might experience throttling due to excessive background jobs, which can be triggered by high-frequency operations or system-wide activities. While customers do not have direct control over the creation or execution of these jobs, awareness of potential throttling is important.
 
-## Throttling for sovereign clouds
-
-Throttling happens at two levels. Azure Resource Manager throttles requests for the subscription and tenant. If the request is under the throttling limits for the subscription and tenant, Resource Manager routes the request to the resource provider. The resource provider applies throttling limits that are tailored to its operations.
-
-Requests are initially throttled per principal ID and per Azure Resource Manager instance in the region of the user sending the request. Requests to the Azure Resource Manager instance in the region are also throttled per principal user ID and per hour. When the request is forwarded to the resource provider, requests are throttled per region of the resource rather than per Azure Resource Manager instance in region of the user. 
-
-> [!NOTE]
-> The limits of a resource provider can differ from the limits of the Azure Resource Manager instance in the region of the user.
-
-The following image shows how throttling is applied as a request goes from the user to Azure Resource Manager and the resource provider. 
-
-:::image type="content" source="./media/request-limits-and-throttling/request-throttling.svg" alt-text="Diagram that shows how throttling is applied as a request goes from the user to Azure Resource Manager and the resource provider.":::
-
-## Subscription and tenant limits
-
-Every subscription-level and tenant-level operation is subject to throttling limits. Subscription requests are ones that involve passing your subscription ID, such as retrieving the resource groups in your subscription. For example, sending a request to `https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups?api-version=2022-01-01` is a subscription-level operation. Tenant requests don't include your subscription ID, such as retrieving valid Azure locations. For example, sending a request to `https://management.azure.com/tenants?api-version=2022-01-01` is a tenant-level operation.
-
-The default throttling limits per hour are shown in the following table.
-
-| Scope | Operations | Limit |
-| ----- | ---------- | ------- |
-| Subscription | reads | 12,000 |
-| Subscription | deletes | 15,000 |
-| Subscription | writes | 1,200 |
-| Tenant | reads | 12,000 |
-| Tenant | writes | 1,200 |
-
-These limits are scoped to the security principal (user or application) making the requests and the subscription ID or tenant ID. If your requests come from more than one security principal, your limit across the subscription or tenant is greater than 12,000 and 1,200 per hour.
-
-These limits apply to each Azure Resource Manager instance. There are multiple instances in every Azure region, and Azure Resource Manager is deployed to all Azure regions. So, in practice, the limits are higher than these limits. Different instances of Azure Resource Manager usually handle the user's requests.
-
-The remaining requests are returned in the [response header values](#remaining-requests).
-
 ## Resource provider limits
 
 Resource providers apply their own throttling limits. Within each subscription, the resource provider throttles per region of the resource in the request. Because Resource Manager throttles by instance of Resource Manager, and there are several instances of Resource Manager in each region, the resource provider might receive more requests than the default limits in the previous section.

articles/backup/backup-azure-arm-restore-vms.md

@@ -248,7 +248,7 @@ If CRR is enabled, you can view the backup items in the secondary region.
 
 The secondary region restore user experience is similar to the primary region restore user experience. When configuring details in the Restore Configuration pane to configure your restore, you're  prompted to provide only secondary region parameters.
 
-Currently, secondary region [RPO](azure-backup-glossary.md#recovery-point-objective-rpo) is _36 hours_. This is because the RPO in the primary region is _24 hours_ and can take up to _12 hours_ to replicate the backup data from the primary to the secondary region.
+For Azure VM backups, the secondary region [RPO](azure-backup-glossary.md#recovery-point-objective-rpo) can be up to _36 hours_ in the worst case. With the Standard policy, the primary region RPO is up to _24 hours_, and replication to the secondary region can take up to _12 hours_. With the Enhanced policy, more frequent local recovery point creation can improve the best-case achievable secondary region RPO. However, because vaulting is daily, the worst-case secondary region RPO can still be up to _36 hours_.
 
 :::image type="content" source="./media/backup-azure-arm-restore-vms/secondary-region-restore.png" alt-text="{alt-text}":::Screenshot shows how to start secondary region restore of a VM. ":::
 

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

@@ -457,7 +457,7 @@ sections:
 
       - question: When Vault is configured with CRR, what happens to the secondary data if the primary region fails?
         answer: |
-          Backup data fully replicated to the secondary region before the failure of the primary region will remain intact. This remains the case even after the primary region has recovered from the failure. In other words, the virtual machine can be recovered in the secondary region with the data it had before the failure as per the replication schedule. Note that the RPO for the secondary region is 36 hours i.e., data takes approximately 36 hours to be fully replicated from primary to the secondary region.
+          Backup data fully replicated to the secondary region before the failure of the primary region remains intact. This remains true even after the primary region recovers from the failure. In other words, the virtual machine can be recovered in the secondary region with the data it had before the failure, based on the replication schedule. For Azure VM backups, the secondary region RPO can be up to 36 hours in the worst case. With the Standard policy, this is based on up to 24 hours in the primary region plus up to 12 hours for replication to the secondary region. With the Enhanced policy, more frequent local recovery point creation can improve the best-case achievable secondary region RPO, but the worst-case can still be up to 36 hours.
 
       - question: When I update the backup policy, why is the expiry time not getting updated immediately?
         answer: |

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

@@ -47,7 +47,9 @@ Azure Backup takes snapshots according to the backup schedule.
 
 If you have opted for application or file-system-consistent backups, the VM needs to have a backup extension installed to coordinate for the snapshot process. For [*agentless multi-disk crash-consistent* backups](backup-azure-vms-agentless-multi-disk-crash-consistent-overview.md), the VM agent is not required for snapshots.
 
-- **Windows VMs:** For Windows VMs, the Backup service coordinates with VSS to take an app-consistent snapshot of the VM disks.  By default, Azure Backup takes a full VSS backup (it truncates the logs of application such as SQL Server at the time of backup to get application level consistent backup).  If you're using a SQL Server database on Azure VM backup, then you can modify the setting to take a VSS Copy backup (to preserve logs). For more information, see [this article](./backup-azure-vms-troubleshoot.md#troubleshoot-vm-snapshot-issues).
+- **Windows VMs:** For Windows VMs, Azure Backup coordinates with VSS to take an application-consistent snapshot. For VMs running SQL Server, Azure VM Backup triggers a VSS Full (Copy-Only) backup by default to avoid affecting the SQL backup chain used by other backup tools. Copy-Only backups do not truncate SQL Server transaction logs. If you require log truncation (and understand the impact on the SQL backup chain), you can opt in to a VSS Full (Non-Copy-Only) backup by using the UseVssFullBackup registry setting. For more information, see [this article](./backup-azure-vms-troubleshoot.md#troubleshoot-vm-snapshot-issues).
+>[!Note]
+> Azure VM Backup is a VM-level backup. If you need database-level point-in-time recovery using transaction logs, use [Azure Backup for SQL Server in Azure VM (workload backup)](backup-azure-sql-database.md).
 
 - **Linux VMs:** To take app-consistent snapshots of Linux VMs, use the Linux pre-script and post-script framework to write your own custom scripts to ensure consistency.
 

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

@@ -556,17 +556,16 @@ Verify the VM Agent version on Windows VMs:
 
 ## Troubleshoot VM snapshot issues
 
-VM backup relies on issuing snapshot commands to underlying storage. Not having access to storage or delays in a snapshot task run can cause the backup job to fail. The following conditions can cause snapshot task failure:
+VM backup relies on issuing snapshot commands to underlying storage. Lack of storage access or delays during a snapshot task run can cause the backup job to fail. The following conditions can cause snapshot task failure:
+* **VMs with SQL Server configured can experience snapshot delays** when Azure VM Backup interacts with the SQL Server VSS Writer. For Windows VMs running SQL Server, Azure VM Backup currently triggers a VSS Full (Copy-Only) backup by default to avoid impacting SQL Server differential and transaction log backup chains used by other backup tools. Copy-Only VSS backups do not truncate SQL Server transaction logs.
 
-* **VMs with SQL Server backup configured can cause snapshot task delay**. To avoid that, currently VM backup creates a VSS full backup (Copy-Only) on Windows VMs. If you need a VSS Full backup (Non-copy Only) then add the following registry key on the Windows VM:
+If you explicitly require a VSS Full (Non-Copy-Only) backup, which can truncate SQL Server transaction logs and may affect the SQL backup chain, configure the following registry key on the Windows VM:
 
    ```console
-   REG ADD "HKLM\SOFTWARE\Microsoft\BcdrAgent" /v UseVSSCopyBackup /t REG_SZ /d True /f   
+REG ADD "HKLM\SOFTWARE\Microsoft\BcdrAgent" /v UseVssFullBackup /t REG_SZ /d True /f
    ```
 
-  >[!Note]
-  >Setting UseVSSCopyBackup = True enables VSS Copy-Only backups. This ensures that snapshots aren't delayed and that any log chains managed by other backup products (such as SQL Server log backups) are not broken.
-  If the key is set to False or not present, Azure Backup defaults to VSS Full backups, which may truncate application logs to achieve application-consistent backups.
+If UseVssFullBackup is set to False or not present, Azure VM Backup continues to use VSS Full (Copy-Only) backups by default.
 
 * **VM status is reported incorrectly because the VM is shut down in RDP**. If you used the remote desktop to shut down the virtual machine, verify that the VM status in the portal is correct. If the status isn't correct, use the **Shutdown** option in the portal VM dashboard to shut down the VM.
 * **The VM runs at high CPU or memory**. If the virtual machine runs at high memory or CPU usage, more than 90 percent, your snapshot task is queued and delayed. Eventually it times out. If this issue happens, try an on-demand backup.

articles/backup/backup-create-recovery-services-vault.md

@@ -52,7 +52,7 @@ Before you begin, consider the following information:
 - A list of supported managed types and regions is available in the [Support matrix for Azure Backup](backup-support-matrix.md#cross-region-restore).
 - Cross Region Restore incurs extra charges for use. After you enable Cross Region Restore, it might take up to 48 hours for the backup items to be available in secondary regions. [Learn more about pricing](https://azure.microsoft.com/pricing/details/backup/).
 - Cross Region Restore currently can't be reverted to GRS or LRS after the protection starts for the first time.
-- Currently, the recovery point objective (RPO) for the secondary region is 36 hours. The RPO in the primary region is 24 hours and can take up to 12 hours to replicate the backup data from the primary to the secondary region.
+- Secondary region recovery point objective (RPO) can vary by workload type and policy. For Azure VM backups, the secondary region RPO can be up to 36 hours in the worst case. With the Standard policy, the primary region RPO is up to 24 hours, and replication to the secondary region can take up to 12 hours. With the Enhanced policy, more frequent local recovery point creation can improve the best-case achievable secondary region RPO, but the worst-case can still be up to 36 hours. For workload-specific guidance, see the relevant restore documentation.
 - Permissions are required to use Cross Region Restore. For more information, see [Use Azure role-based access control (RBAC) to manage Azure Backup recovery points](backup-rbac-rs-vault.md#minimum-role-requirements-for-azure-vm-backup).
 
 A vault created with GRS redundancy includes the option to configure Cross Region Restore. Every GRS vault has a banner that links to the documentation.

articles/container-apps/TOC.yml

@@ -271,36 +271,42 @@ items:
     - name: Overview
       href: observability.md
       displayName: Observability overview
-    - name: Troubleshoot and resolve issues with an agent
+    - name: Develop and debug with real-time logs
+      items:
+        - name: Log streaming
+          href: log-streaming.md
+        - name: Container console
+          href: container-console.md
+        - name: Container debug console
+          href: container-debug-console.md
+    - name: Monitor production workloads
+      items:
+        - name: Application logging
+          href: logging.md
+        - name: Logging options
+          href: log-options.md
+        - name: Log monitoring
+          href: log-monitoring.md
+        - name: Metrics
+          href: metrics.md
+        - name: Alerts
+          href: alerts.md
+    - name: End-to-end tracing and dashboards
+      items:
+        - name: Aspire Dashboard
+          href: aspire-dashboard.md
+        - name: OpenTelemetry agents
+          href: opentelemetry-agents.md
+        - name: Grafana dashboards
+          href: grafana-dashboards.md
+    - name: Troubleshoot and resolve issues with SRE agent
       items:
         - name: Overview
           href: ../sre-agent/overview.md
         - name: Use an SRE agent
           href: ../sre-agent/usage.md
         - name: Fix app issues with an SRE agent
           href: ../sre-agent/troubleshoot-azure-container-apps.md
-    - name: Application logging
-      href: logging.md
-    - name: Real time data
-      href: aspire-dashboard.md
-    - name: Logging options
-      href: log-options.md
-    - name: Log streaming
-      href: log-streaming.md
-    - name: Container console
-      href: container-console.md
-    - name: Container debug console
-      href: container-debug-console.md
-    - name: Metrics
-      href: metrics.md
-    - name: Log monitoring
-      href: log-monitoring.md
-    - name: Alerts
-      href: alerts.md
-    - name: OpenTelemetry agents
-      href: opentelemetry-agents.md
-    - name: Grafana dashboards
-      href: grafana-dashboards.md
 - name: Scaling & performance
   items:
     - name: Overview