The recovery point objective (RPO) and the recovery time objective (RTO) are two very specific parameters that are closely associated with recovery. The RTO is how long you can basically go without a specific application. This is often associated with your maximum allowable or maximum tolerable outage.
The RTO is really used to dictate your use of replication or backup to tape or disk. That also dictates what you will put together for an infrastructure whether it's a high-availability cluster for seamless failover or something more modest. If your RTO is zero (I cannot go down) then you may opt to have a completely redundant infrastructure with replicated data offsite and so on. If your RTO is 48 hours or 72 hours then maybe tape backup is OK for that specific application. That's the RTO.
The RPO is slightly different. This dictates the allowable data loss -- how much data can I afford to lose? In other words, if I do a nightly backup at 7:00 p.m. and my system goes up in flames at 4:00 p.m. the following day, everything that was changed since my last backup is lost. My RPO in this particular context is the previous day's backup. If I'm a company that does online transaction processing -- American Express for example -- well maybe my RPO is down to the last, latest transaction, the latest bits of information that came in. Again, that dictates the kind of data protection solution you want in place.
So both of them, RTO and RPO, really influence the kind of redundancy or backup infrastructure you will put together. The tighter the RTO, and the tighter the RPO, the more money you will spend on your infrastructure.