Addressed MVP inputs - RPO and RTO definition updates

Author: AbhishekMallick-MS

articles/backup/azure-backup-glossary.md

@@ -4,7 +4,7 @@ description: This article defines terms helpful for use with Azure Backup.
 ms.topic: conceptual
 ms.service: backup
 ms.custom: devx-track-azurepowershell, devx-track-arm-template, devx-track-azurecli, engagement-fy24
-ms.date: 01/22/2024
+ms.date: 03/21/2024
 author: AbhishekMallick-MS
 ms.author: v-abhmallick
 ---
@@ -257,13 +257,17 @@ Refer to the [Azure REST API documentation](/rest/api/azure/).
 
 A user-defined rule that specifies how long backups should be retained.
 
-## RPO (Recovery Point Objective)
+## Recovery Point Objective (RPO)
 
-RPO indicates the maximum data loss that is possible in a data-loss scenario. This is determined by backup frequency.
+PO indicates the maximum acceptable amount of data-loss measured in time. For example, if a disaster occurs at *12:00 PM* and the last backup was at *10:00 AM*, the RPO is *two hours*. This means that the organization is willing to accept losing two hours’ worth of data.
 
-## RTO (Recovery Time Objective)
+## Recovery Time Objective (RTO)
 
-RTO indicates the maximum possible time in which data can be restored to the last available point-in-time after a data loss scenario.
+RTO is the target time within which a business process must be restored after a disaster occurs to avoid unacceptable consequences. For instance, if a critical application goes down due to a server failure, and the business can only tolerate a *maximum of four hours of downtime*, then the RTO is *four hours*.
+
+The following example scenario describes both RPO and RTO concepts:
+
+Your company has an RPO of *1 hour* for your customer database, which means you perform backups every hour. If a data loss incident occurs, you'll lose not more than *one hour of data*. When you set RTO to *3 hours*, then in the event of a system failure, you aim to restore access to the database within 3 hours to minimize impact on operations.
 
 ## Scheduled backup