Merge pull request #308680 from MicrosoftDocs/main

Auto Publish – main to live - 2025-11-24 06:00 UTC

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

articles/azure-app-configuration/howto-geo-replication.md

@@ -375,6 +375,11 @@ appConfig, err := azureappconfiguration.Load(ctx, authOptions, options)
 
 ---
 
+## Use geo-replication with Azure Front Door
+
+Replica discovery and load balancing cannot be enabled when using Azure Front Door. To use geo-replication with Azure Front Door, add replicas to your Azure Front Door origin group. For more information, see [Origins and origin groups in Azure Front Door](/azure/frontdoor/origin).
+
+
 ## Next steps
 
 > [!div class="nextstepaction"]

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

@@ -63,7 +63,12 @@ Azure Data Lake Storage protection has the following supported and unsupported s
 - 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.
 - 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 expiry is set on blobs via SetBlobExpiry API or PutBlob/PutBlock options. Once expired, expired blobs remain in restore points, creating inconsistencies in future restore points. Recommendation is to not use blob expiry.
+- 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:
+  - 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-enabled & NFS accounts are not supported for backup. Backup jobs may stall if SFTP-uploaded blobs encountered.
 - $web container cannot be restored as $web on the target. Use the renameTo option and restore it with a different container name.

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

@@ -58,7 +58,7 @@ If you don't have permissions, you can [restore a disk](#restore-disks), and the
 
 To select a restore point for a VM restore, follow these steps:
 
-1. Go to **Business Continuity Center** in the [Azure portal](https://portal.azure.com/) and select **Recover**.
+1. Go to **Resiliency** in the [Azure portal](https://portal.azure.com/) and select **Recover**.
 
     :::image type="content" source="./media/backup-azure-arm-restore-vms/select-recover.png" alt-text="Screenshot shows how to start VM restore." lightbox="./media/backup-azure-arm-restore-vms/select-recover.png":::
 
@@ -169,7 +169,7 @@ After the disk is restored, use the template that was generated as part of the r
 
 1. Go to the **Recovery Services vault**, and then select **Monitoring** > **Backup Jobs**.
 
-   Alternatively, you can go to **Business Continuity Center**, and then select **Monitoring + Reporting** > **Jobs**. 
+   Alternatively, you can go to **Resiliency**, and then select **Monitoring + Reporting** > **Jobs**. 
 
 1. On the **Backup Jobs** pane, select the relevant restore job.