RTO (Recovery Time Objective) and RPO (Recovery Point Objective) are the two central metrics of any Business Continuity and Disaster Recovery strategy. RTO is the maximum acceptable time to restore a system or service after an incident; RPO is the maximum amount of data (measured in time) that is acceptable to lose. Together, they inform investment in redundant infrastructure.
A concrete example: an ERP with an RTO of 4 hours and an RPO of 1 hour means 'after an incident, the system must be back within 4 hours at most, and can lose at most 1 hour of data'. This decision drives technology — a daily backup is far from sufficient (RPO 24h), while synchronous replication to a secondary datacentre achieves it (RTO minutes, RPO close to zero but at a much higher cost).
In conversations with customers, INFOS often starts by defining RTO/RPO per critical process — not 'we want high availability for everything', but 'invoicing has an RTO of 2h, e-commerce 30min, BI 24h'. The redundancy architecture is derived from this mapping, with optimised cost. Architectures that treat everything with the same criticality are expensive and frequently over-dimensioned in the wrong places.