RTO (Recovery Time Objective) e RPO (Recovery Point Objective) são as duas métricas centrais de qualquer estratégia de Business Continuity e Disaster Recovery. RTO é o tempo máximo aceitável para restaurar um sistema ou serviço após incidente; RPO é a quantidade máxima de dados (medida em tempo) que é aceitável perder. Juntos, informam investimento em infraestrutura redundante.
Exemplo concreto: um ERP com RTO de 4 horas e RPO de 1 hora significa 'após incidente, o sistema tem de estar de volta em 4 horas no máximo, e pode perder no máximo 1 hora de dados'. Esta decisão dirige tecnologia — backup diário está longe de suficiente (RPO 24h), replicação síncrona para datacenter secundário consegue (RTO minutos, RPO próximo de zero mas custo muito maior).
Em conversas com clientes, a INFOS começa frequentemente por definir RTO/RPO por processo crítico — não 'queremos alta disponibilidade para tudo', mas 'faturação tem RTO 2h, e-commerce 30min, BI 24h'. A arquitectura de redundância derivou-se deste mapeamento, com custo optimizado. Arquitecturas que tratam tudo com a mesma criticidade são caras e frequentemente mal dimensionadas em cima.