RPO (Recovery Point Objective) determines how much data loss is acceptable, expressed in time; RTO (Recovery Time Objective) determines how long recovery may take at most.
RPO looks backward from the moment of failure. If your last backup is an hour old, in that scenario you lose an hour's worth of changes. The more frequently a backup is made (every 15 minutes instead of daily), the smaller the RPO. An accounting system can often work with an RPO of several hours; a webshop or transaction system usually wants minutes.
RTO looks forward: how much time do you need to be fully operational again? That includes not just restoring data, but also starting systems, restoring connections, and verification. A low RTO almost always costs more. The right RTO isn't "as low as possible," but "as low as the impact of downtime justifies."
A service can have an excellent RPO (backup every 15 minutes) but a poor RTO (manual recovery that takes a day), or the other way around. Assess them separately.
First determine an acceptable RPO and RTO per system; that's a business decision. Then don't ask a provider "how fast is your recovery?" but rather: "what is your guaranteed RPO and RTO for this type of workload, and is that in an SLA or is it a target?" That distinction often says more than the figure itself.
RPO and RTO fall under our Recovery & continuity criterion in the provider comparison. We note whether a provider publicly guarantees values or only states them as indicative. For several providers, RTO depends on contract or configuration; that's stated in the justification.
In theory, yes, with continuous replication instead of periodic backups, but that's more expensive and more complex. For many SMB workloads, an RPO of 15 minutes to an hour is a strong starting position.
That depends on the system. For critical systems, under four hours is often the target; for less critical systems, a day can be acceptable. More important than a single number is that you set it deliberately, per system.