Merge pull request #314217 from akarshprabhu/main

CRR RPO and SQL VSS clarifications

Author: prmerger-automator[bot]

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.