PT 
EN 
ES 
Todo plano de recuperação carrega dois números. O RTO, que é o tempo máximo aceitável entre a parada e o retorno do serviço, e o RPO, que é a perda máxima de dados aceitável, medida em tempo. Quase toda empresa de médio e grande porte tem esses dois números escritos em algum documento.
O que quase nenhuma consegue mostrar é como chegou neles.
A diferença importa porque número sem método não sobrevive ao primeiro incidente. Ele foi definido numa reunião, por consenso, e no dia da crise se descobre que a arquitetura nunca foi dimensionada para atendê-lo, ou que o prazo prometido não incluía metade do trabalho que a retomada exige. Este artigo trata do método: de onde vem cada número, quem responde por ele e como verificar se ele faz sentido antes de virar compromisso.
Se a dúvida ainda está um passo atrás, no que é um plano de recuperação e o que entra nele, o artigo sobre DRP cobre essa camada.
Primeiro vem o MTD, e ele não é o RTO
Aqui está o erro mais comum, e ele não parece erro.
A TI pergunta ao negócio quanto tempo a operação aguenta sem o sistema. O negócio responde 72 horas. A TI anota RTO de 72 horas. Todo mundo sai da reunião satisfeito.
O número que acabou de ser definido não é o RTO. É o MTD.
O NIST SP 800-34 Rev. 1, guia de planejamento de contingência do instituto de padrões americano, separa os dois com clareza. O MTD, Maximum Tolerable Downtime, é o tempo total de indisponibilidade que o responsável pelo sistema está disposto a aceitar, com todos os impactos considerados. O RTO é o tempo máximo que um recurso pode ficar indisponível antes de haver impacto inaceitável sobre os outros recursos, sobre os processos de negócio e sobre o próprio MTD.
A frase do documento que resolve a confusão é esta: como o RTO precisa garantir que o MTD não seja excedido, o RTO normalmente tem de ser mais curto que o MTD.
O motivo é prático. Entre o sistema voltar a responder e a operação voltar a funcionar existe trabalho. Lançamentos feitos à mão durante a parada precisam ser digitados. Integrações que ficaram paradas precisam processar a fila acumulada. Alguém precisa conferir se os saldos fecham antes de liberar o faturamento. Esse tempo não é da TI, mas consome o mesmo relógio.
Então, se o negócio aguenta 72 horas e a reconciliação leva 24, o RTO é de 48 horas. O exemplo que o próprio NIST usa no modelo de análise de impacto é exatamente esse: processo de pagamento a fornecedor com MTD de 72 horas, RTO de 48 horas e RPO de 12 horas.
A conta é simples. Fazê-la na ordem errada é o que produz planos que falham dentro do prazo prometido.
A pergunta não é sobre o sistema, é sobre o processo
A segunda troca que atrasa o trabalho é perguntar o RTO do ERP.
Ninguém sabe responder isso, e quem responde está adivinhando. O ERP sustenta faturar, comprar, pagar, fechar o mês e consultar histórico, e esses cinco processos têm tolerâncias completamente diferentes. Faturar não espera um dia. Consultar histórico espera uma semana sem que ninguém perceba.
O NIST organiza a análise de impacto em três passos, e o primeiro é determinar os processos de negócio e a criticidade da recuperação. A unidade de análise é o processo, não o servidor. Só depois vêm os recursos que cada processo consome, e por último a ordem de recuperação desses recursos.
Na prática isso inverte a conversa. Em vez de listar sistemas e perguntar quanto cada um aguenta, você lista o que a empresa faz, descobre quanto cada atividade aguenta, e aí mapeia de quais sistemas cada uma depende. O RTO de um servidor passa a ser consequência: é o prazo mais apertado entre os processos que dependem dele.
O efeito colateral é bem-vindo. Quando o número sai do processo, ele deixa de ser opinião da TI e passa a ter dono na área de negócio.
Como transformar “é crítico” em número comparável
Na primeira rodada, tudo é crítico. Isso não é má vontade, é falta de escala. Sem uma régua comum, “crítico” é a única palavra disponível para dizer “importante para mim”.
O NIST resolve isso pedindo que a organização crie categorias de impacto e atribua valores a elas, de forma a medir o nível de severidade que uma parada causaria. O exemplo do documento usa custo como categoria, com três faixas: severo, quando horas extras, contratação temporária e multas passam de um milhão de dólares; moderado, na casa dos quinhentos e cinquenta mil; e mínimo, na casa dos setenta e cinco mil. O guia é explícito ao dizer que esses valores são apenas exemplo e devem ser revistos para refletir a realidade de cada organização.
O valor dessa régua não está na precisão. Está em obrigar a comparação. Quando duas áreas precisam encaixar o próprio processo na mesma escala de reais, a lista de prioridades aparece sozinha.
Três perguntas que funcionam melhor que “é crítico”:
O que acontece na quarta hora? A pergunta genérica recebe resposta genérica. A pergunta com hora marcada recebe cenário: na quarta hora a transportadora vai embora sem carregar, e a entrega atrasa um dia.
Existe um jeito manual de seguir? Se existe, o MTD é mais longo do que parecia. Se não existe, é mais curto. O NIST pede essa informação de forma explícita no levantamento, e é a resposta que mais muda números.
Por quanto tempo o jeito manual aguenta? Caderno e planilha funcionam por algumas horas. Depois disso, a fila de digitação passa a ser o novo problema, e esse tempo entra no desconto do MTD.
O RPO é uma pergunta sobre retrabalho, não sobre backup
O RPO costuma ser tratado como um parâmetro técnico da rotina de cópia. Não é.
O NIST é direto em dois pontos. O primeiro: o RPO representa o ponto no tempo, anterior à parada, até o qual os dados do processo precisam ser recuperados, considerando a cópia mais recente disponível. O segundo, que quase sempre passa batido: diferente do RTO, o RPO não é considerado parte do MTD. Ele é um fator separado, de quanta perda de dados o processo tolera.
Isso tem uma consequência prática. Quem responde o RPO não é quem administra o backup, é quem vai redigitar. A pergunta correta é quantas horas de lançamento a equipe consegue refazer à mão sem parar o resto do trabalho, e com que risco de erro.
E tem um teste de honestidade que vale fazer antes de publicar o número. O RPO não pode ser menor que o intervalo entre as cópias. RPO de quinze minutos com backup noturno é intenção, não capacidade. Se o número que o negócio precisa é mais curto que a janela atual, a conversa deixou de ser sobre o número e passou a ser sobre mudar a tecnologia de cópia, o que o artigo sobre backup em nuvem detalha.
O teste de sanidade: o número cabe na tecnologia e no orçamento
Definido o MTD por processo, derivado o RTO e acordado o RPO, falta a parte que o negócio não tem como saber sozinho: quanto cada faixa custa.
O NIST descreve isso como um balanceamento de custo. Quanto mais longa a parada, mais caro o prejuízo. Quanto mais curto o RTO, mais caras as soluções de recuperação. O documento observa que o ponto de equilíbrio entre essas duas curvas é diferente para cada organização e cada sistema, porque depende das restrições financeiras e dos requisitos de operação.
Para transformar isso em ordem de grandeza, a documentação de arquitetura da AWS publica as faixas que cada estratégia atende em REL13-BP02:
- Backup e restauração: RPO em horas, RTO em até 24 horas. Com cópias contínuas e recuperação para um ponto no tempo, o RPO pode cair para a casa dos cinco minutos.
- Pilot light: RPO em minutos, RTO em dezenas de minutos.
- Warm standby: RPO em segundos, RTO em minutos.
- Ativo-ativo em mais de uma região: RPO próximo de zero, RTO potencialmente zero.
Essas faixas servem como checagem, não como catálogo. Se o negócio pediu RTO de dez minutos e a arquitetura atual é backup e restauração, a distância não se cobre com esforço no dia do incidente. Ela se cobre com investimento, ou o número muda.
Vale registrar também o que os provedores não garantem. A Microsoft afirma na documentação do seu framework de arquitetura que publica garantias de RTO e RPO apenas para alguns produtos. Para o resto, o número é responsabilidade de quem desenhou a solução, e não do contrato de serviço.
E quando não dá? O NIST prevê o caso: quando não é viável atender o RTO de imediato e o MTD é inflexível, a situação deve ser documentada formalmente, com um plano de ação e marcos para corrigi-la. Registrar a lacuna é uma decisão defensável. Escrever um número que ninguém consegue cumprir não é.
O RTO e a meta de disponibilidade precisam fechar
Existe uma contradição que aparece em quase todo documento de requisitos e quase nunca é notada, porque os dois números moram em páginas diferentes.
Numa página está a meta de disponibilidade, normalmente 99,9%. Na outra está o RTO, normalmente algumas horas.
A tabela de objetivos de nível de serviço do framework de arquitetura da Microsoft mostra o que 99,9% permite: 43,20 minutos de indisponibilidade por mês, ou 8,76 horas por ano.
Compare com o RTO. Um único incidente que consuma um RTO de quatro horas já gasta quase metade do orçamento anual de indisponibilidade de uma meta de 99,9%. Dois incidentes assim no ano estouram a meta, mesmo que os dois tenham sido atendidos exatamente dentro do prazo combinado.
Não é que um dos números esteja errado. É que faltou o terceiro: quantos incidentes por ano a meta pressupõe. Sem ele, os dois primeiros não se conversam, e a empresa cumpre o RTO e descumpre a meta no mesmo incidente.
Quem assina o número
Na definição do NIST, o MTD é o tempo que o responsável pelo sistema está disposto a aceitar. Está disposto, no singular. É uma pessoa, não um comitê.
Isso tem efeito prático em três momentos. Na definição, porque alguém precisa bancar a escolha quando o custo da arquitetura aparece. No incidente, porque é quem autoriza o retorno à operação normal. E na revisão, porque o número envelhece: processo que mudou de volume, sistema que ganhou integração nova, operação que passou a atender outro fuso.
Por isso a planilha de criticidade precisa de três colunas que costumam faltar: o nome de quem respondeu, a data da resposta e o que dispara uma nova revisão.
Como a Integrity-UX conduz esse trabalho
Começamos pelo levantamento com as áreas de negócio, processo por processo, com a régua de impacto montada antes da primeira reunião. Sai dessa etapa o MTD de cada processo, com dono e data.
Em seguida mapeamos as dependências de cada processo e derivamos o RTO por recurso, descontando o tempo de reprocessamento e conferência. O RPO é acordado com quem faz o lançamento, e conferido contra a janela real das cópias.
Com os números fechados, apresentamos o que cada faixa exige de arquitetura e de investimento, e onde há lacuna entre o que foi pedido e o que a infraestrutura atual entrega. O resultado é uma tabela curta, de processo, MTD, RTO, RPO e estratégia, que cabe numa página e serve de base para o plano de recuperação.
Próximos passos
Se a sua empresa já tem RTO e RPO definidos, vale um teste rápido: pegue o número de um processo e tente responder quem o definiu, em que data, e se ele desconta o tempo de reprocessamento. Se as três respostas não vierem, o número precisa de revisão antes de qualquer investimento em arquitetura.
Para entender onde esses números entram no plano completo, o artigo sobre DRP trata da estrutura do documento e da frequência de teste. Para a camada de cópias, que é onde o RPO se realiza ou não, o artigo sobre backup em nuvem cobre retenção e a regra 3-2-1.
Se preferir conversar sobre o seu caso, a página de DRP tem o contato direto.
Perguntas frequentes
Qual a diferença entre MTD e RTO?
O MTD é o tempo total de indisponibilidade que a empresa aceita para um processo de negócio. O RTO é o prazo para o recurso de TI voltar a funcionar. Como entre o sistema voltar e a operação voltar existe reprocessamento e conferência, o RTO precisa ser mais curto que o MTD. O NIST SP 800-34 Rev. 1 registra essa relação de forma explícita.
Quem define o RTO e o RPO?
O negócio define a tolerância, e a TI traduz essa tolerância em arquitetura e custo. Na definição do NIST, o MTD é o tempo que o responsável pelo sistema aceita, o que implica uma pessoa nomeada, não um consenso de reunião.
O RPO pode ser menor que o intervalo do backup?
Não. O RPO é limitado pela cópia mais recente disponível. Se a cópia é noturna, o RPO real é de até 24 horas, qualquer que seja o número escrito no documento. Reduzir o RPO exige mudar a frequência ou a tecnologia de cópia.
Como definir RTO se todas as áreas dizem que o sistema é crítico?
Criando uma régua de impacto com faixas e valores, como o NIST recomenda, e perguntando por cenário com hora marcada em vez de criticidade em abstrato. Quando as áreas precisam encaixar os próprios processos na mesma escala, a priorização aparece.
RTO de quatro horas é compatível com 99,9% de disponibilidade?
Depende de quantos incidentes por ano a meta pressupõe. Uma meta de 99,9% permite 8,76 horas de indisponibilidade por ano, segundo a tabela de nível de serviço da Microsoft. Um único incidente de quatro horas consome quase metade desse orçamento.
