Flávio pretende elaborar um plano de recuperação de desastres para um sistema vital de TI, considerando um RPO adequado às necessidades de negócio da sua organização. Para isso, Flávio precisa, necessariamente, conhecer
- A)o tempo máximo aceitável para o sistema se recompor e retomar as atividades após sofrer uma interrupção.
Errada, porque descreve o RTO, que é o tempo máximo para o sistema voltar a funcionar após a interrupção.
- B)a quantidade de informação que a empresa toleraria perder, porque não seriam recuperadas na retomada do sistema.
Certa, porque define o RPO, isto é, a quantidade de dados que a empresa admite perder até a recuperação do sistema.
- C)a quantidade de ataques cibernéticos sobre o sistema evitados nos últimos 12 meses.
Errada, pois isso não mede continuidade de negócios nem recuperação de desastre; é um dado sem relação com RPO.
- D)o tempo médio necessário para reparar um componente ou dispositivo do sistema com falha.
Errada, porque isso é o MTTR, o tempo médio para reparar um componente com falha, e não RPO.
- E)o custo de manutenção, para que o sistema continue funcionando adequadamente dentro da empresa.
Errada, porque custo de manutenção não define objetivo de recuperação, e sim despesa operacional ou de sustentação do sistema.
Gabarito: B
Quando a empresa fala em plano de recuperação de desastres, ela está pensando em voltar a operar depois de uma parada, mas com um detalhe importante: não basta “voltar”, é preciso voltar dentro de limites aceitáveis para o negócio. É aí que aparecem conceitos como RTO e RPO, que vivem andando juntos e confundindo muita gente em prova. O RTO (Recovery Time Objective) é o tempo máximo tolerável para restaurar o sistema após a interrupção. Já o RPO (Recovery Point Objective) é o quanto de dados a organização aceita perder em caso de desastre, ou seja, qual é o ponto de recuperação das informações. Em linguagem prática: o RTO olha para o relógio; o RPO olha para o volume de informação que pode ser perdido até o último backup ou sincronização aceitável. Por isso, se Flávio quer definir um RPO adequado às necessidades do negócio, ele precisa saber qual quantidade de informação a empresa tolera perder sem comprometer a operação. Se o sistema cair, o foco do RPO é responder: “até que ponto no tempo os dados precisam ser recuperados?”. Essa distinção é clássica em Segurança da Informação e Continuidade de Negócios, alinhada às boas práticas de gestão de continuidade, como as da família ISO 22301. Em prova, a banca adora trocar tempo por dados para ver se você escorrega na casca da banana.