I'm wrestling with RPO calculation in a database outage situation as follows:  I have a backup from 1 hour ago and it takes me 1 hour to recover.  The Database has now been unavailable to the application for 2 hours of read/write transactions.  Do I have a 1 hour RPO or 2 Hour?  Another way to look at it is whether the business outage time counts as "data loss".

Considering real world implications, how good is the backup from one hour ago? The scenario states that the DB has been unavailable to the application for 2 hours. If it was merely a loss in connectivity between the DB and the application that is one thing, but if the DB is malfunctioning then the backup may not be usable. 

Recovery Point Objective (RPO) defines the maximum acceptable amount of data loss measured in time. It reflects how far back in time your data can be recovered from backup before it impacts business viability. On the other hand, Recovery Time Objective (RTO) is more technology-focused — it represents the time taken to restore the affected system or application and make it operational again.

In your example, if the RPO is stated as 1 hour but it takes an additional hour to restore the application, then effectively, the business may lose up to 2 hours of data if there is no alternate mechanism in place to continue the process. This implies that in practical terms, your RPO should be 2 hours, unless compensating measures exist.

It’s also important to understand that RPO and RTO can be decoupled. For instance, the process might be able to continue through alternate means (manual overrides, shadow systems, etc.) even while recovery is ongoing. In such cases, RTO may remain higher, but effective RPO can still be kept low if the process continuity is maintained.

Lastly, while RPO is usually less than or equal to RTO, business continuity planning often allows flexibility — especially when non-digital workarounds are viable. The key is to focus on process continuity, not just system recovery.