Merge pull request #312191 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: Taojunshen

articles/backup/backup-azure-sap-hana-database-troubleshoot.md

@@ -152,10 +152,10 @@ See the [prerequisites](tutorial-backup-sap-hana-db.md#prerequisites) and [What
 
 ### UserErrorRecoverySysScriptFailedToTriggerRestore
 
-**Error message** | `RecoverySys.py could not be run successfully to restore System DB.`
+**Error message** | `recoverSys.py could not be run successfully to restore System DB.`
 -------- | ---------
-**Possible causes** | Possible causes for System DB restore to fail are:<ul><li>Azure Backup is unable to find **Recoverysys.py** on the HANA machine. It happens when the HANA environment isn't set up properly.</li><li>**Recoverysys.py** is present, but when you trigger this script, it fails to invoke HANA to perform the restore.</li><li>Recoverysys.py has successfully invoked HANA to perform the restore, but HANA fails to restore.</li></ul>
-**Recommended action** | <ul><li>For issue 1, work with the SAP HANA team to fix the issue.</li><li>For 2 and 3, run the HDSetting.sh command in sid-adm prompt and see the log trace. For example, _/usr/sap/SID/HDB00/HDBSetting.sh_.</li></ul>Share these findings with the SAP HANA team to get the issue fixed.
+**Possible causes** | Possible causes for System DB restore to fail are:<ul><li>Azure Backup is unable to find **recoverSys.py** on the HANA machine. It happens when the HANA environment isn't set up properly.</li><li>**recoverSys.py** is present, but when you trigger this script, it fails to invoke HANA to perform the restore.</li><li>recoverSys.py has successfully invoked HANA to perform the restore, but HANA fails to restore.</li></ul>
+**Recommended action** | <ul><li>For issue 1, work with the SAP HANA team to fix the issue.</li><li>For 2 and 3, run the HDBsettings.sh command in sid-adm prompt and see the log trace. For example, _/usr/sap/SID/HDB00/HDBsettings.sh_.</li></ul>Share these findings with the SAP HANA team to get the issue fixed.
 
 ### UserErrorDBNameNotInCorrectFormat
 
@@ -168,12 +168,12 @@ See the [prerequisites](tutorial-backup-sap-hana-db.md#prerequisites) and [What
 
 **Error message** | `Default sid-adm directory changed.`
 ------- | -------
-**Possible causes** | The default **sid-adm** directory was changed, and **HDBSetting.sh** isn't available in this default directory.
+**Possible causes** | The default **sid-adm** directory was changed, and **HDBsettings.sh** isn't available in this default directory.
 **Recommended action** | If HXE is the SID, ensure that environment variable HOME is set to _/usr/sap/HXE/home_ as **sid-adm** user.
 
 ### UserErrorHDBsettingsScriptNotFound
 
-**Error message** | `HDBSetting.sh file cannot be found.`
+**Error message** | `HDBsettings.sh file cannot be found.`
 --------- | -------
 **Possible causes** | System databases restore failed as the **&lt;sid&gt;adm** user environment couldn't find the **HDBsettings.sh** file to trigger restore.
 **Recommended action** | Work with the SAP HANA team to fix this issue.<br><br>If HXE is the SID, ensure that environment variable HOME is set to _/usr/sap/HXE/home_ as **sid-adm** user.

articles/backup/backup-azure-sap-hana-database.md

@@ -249,7 +249,9 @@ Specify the policy settings as follows:
 1. After you finish defining the backup policy, select **OK**.
 
 > [!NOTE]
-> Each log backup is chained to the previous full backup to form a recovery chain. This full backup will be retained until the retention of the last log backup has expired. This might mean that the full backup is retained for an extra period to make sure all the logs can be recovered. Let's assume a user has a weekly full backup, daily differential and 2 hour logs. All of them are retained for 30 days. But, the weekly full can be really cleaned up/deleted only after the next full backup is available, that is, after 30 + 7 days. For example, a weekly full backup happens on Nov 16th. According to the retention policy, it should be retained until Dec 16th. The last log backup for this full happens before the next scheduled full, on Nov 22nd. Until this log is available until Dec 22nd, the Nov 16th full can't be deleted. So, the Nov 16th full is retained until Dec 22nd.
+> Log and incremental backups are chained to the full backup to form recovery chains. The full backup is retained until the retention of the last dependent backup (log or incremental) expires. This might mean that the full backup is retained for an extra period to make sure all dependent backups can be recovered. Let's assume a user has a weekly full backup, daily incremental and 2 hour logs. All of them are retained for 30 days. But, the weekly full can be really cleaned up/deleted only after the next full backup is available, that is, after 30 + 7 days. For example, a weekly full backup happens on Nov 16th. According to the retention policy, it should be retained until Dec 16th. The last log backup for this full happens before the next scheduled full, on Nov 22nd. Until this log is available until Dec 22nd, the Nov 16th full can't be deleted. So, the Nov 16th full is retained until Dec 22nd. The same logic applies to incremental backups: if daily incrementals have a 30-day retention, the last incremental before the next full (Nov 22nd) expires on Dec 22nd, so the Nov 16th full is also retained until Dec 22nd.
+>
+> If backups are in a soft-deleted state, the same chaining and retention dependencies apply. The soft-deleted backups are also retained for 14 additional days beyond the policy retention period before being permanently deleted.
 
 ## Run an on-demand backup
 

articles/backup/manage-monitor-sql-database-backup.md

@@ -128,6 +128,10 @@ Modify policy to change backup frequency or retention range.
 
 > [!NOTE]
 > Any change in the retention period will be applied retrospectively to all the older recovery points besides the new ones.
+>
+> When you reduce the retention period for differential backups, keep in mind that differential backups are dependent on the previous full backup for recovery. The full backup is retained until the retention of the last differential backup that depends on it expires. For example, if you reduce the differential backup retention from 30 days to 15 days, existing differential backups are cleaned up after 15 days from their creation. However, the full backup that these differentials depend on is retained until all those differentials expire.
+>
+> If differential backups are in a soft-deleted state when a retention policy change is applied, the same dependency rules apply. Soft-deleted backups are retained for an additional 14 days beyond their retention expiry before being permanently deleted.
 
 In the vault dashboard, go to **Manage** > **Backup Policies** and choose the policy you want to edit.
 

articles/backup/sap-hana-database-manage.md

@@ -128,6 +128,10 @@ To modify the policy to change backup types, frequencies, and retention range, f
 >[!NOTE]
 > * Any change in the retention period will be applied to both the new recovery points and, retroactively, to all older recovery points.
 >
+> * When you reduce the retention period for incremental backups, keep in mind that incremental backups are chained to the previous incremental backup and ultimately to the full backup. The full backup is retained until the retention of the last incremental backup that depends on it expires. For example, if you reduce the incremental backup retention from 30 days to 15 days, existing incremental backups are cleaned up after 15 days from their creation. However, the full backup that these incrementals depend on is retained until all those incrementals expire.
+>
+> * If incremental backups are in a soft-deleted state when a retention policy change is applied, the same dependency rules apply. Soft-deleted backups are retained for an additional 14 days beyond their retention expiry before being permanently deleted.
+>
 > * For HANA snapshots, you can edit the HANA instance policy to have a different resource group or another user-assigned managed identity. Currently, the Azure portal performs all validations during the backup configuration only. So, you must assign the required roles on the new snapshot resource group or the new user-assigned identity by using the [CLI scripts](https://github.com/Azure/Azure-Workload-Backup-Troubleshooting-Scripts/tree/main/SnapshotPreReqCLIScripts).
 
 1. On the **Backup center** dashboard, go to **Backup Policies**, and then select the policy you want to edit.

articles/backup/tutorial-sql-backup.md

@@ -191,11 +191,13 @@ To create a backup policy:
 1. After you complete the edits to the backup policy, select **OK**.
 
 > [!NOTE]
-> Each log backup is chained to the previous full backup to form a recovery chain. This full backup is retained until the retention of the last log backup expires. This behavior might mean that the full backup is retained for an extra period to make sure all the logs can be recovered.
+> Log and differential backups are chained to the previous full backup to form recovery chains. The full backup is retained until the retention of the last dependent backup (log or differential) expires. This behavior might mean that the full backup is retained for an extra period to make sure all dependent backups can be recovered.
 >
 > Assume that you have a weekly full backup, a daily differential, and 2-hour logs. All of them are retained for 30 days. But, the weekly full backup can be cleaned up or deleted only after the next full backup is available; that is, after 30 + 7 days.
 >
-> For example, a weekly full backup happens on November 16. According to the retention policy, this backup should be retained until December 16. The last log backup happens before the next scheduled full backup, on November 22. Until this log backup is available on December 22, the November 16 full backup can't be deleted. So, the November 16 full backup is retained until December 22.
+> For example, a weekly full backup happens on November 16. According to the retention policy, this backup should be retained until December 16. The last log backup happens before the next scheduled full backup, on November 22. Until this log backup is available on December 22, the November 16 full backup can't be deleted. So, the November 16 full backup is retained until December 22. The same logic applies to differential backups: if daily differential backups have a 30-day retention, the last differential taken before the next full backup (November 22) expires on December 22, so the November 16 full backup is also retained until December 22.
+>
+> If backups are in a soft-deleted state, the same chaining and retention dependencies apply. The soft-deleted backups are also retained for 14 additional days beyond the policy retention period before being permanently deleted.
 
 ## Run an on-demand backup