title: "Plano de recuperação de desastre em TI: RPO, RTO e como sua empresa se prepara" description: "Entenda RPO e RTO, como montar um plano de recuperação de desastre e por que pequenas empresas também precisam de alta disponibilidade." date: "2026-10-05" image: "/assets/images/blog/recuperacao-desastre-ti-dr.jpg" tags: ["servidores", "disaster recovery", "backup", "dicas"] author: "Work Technology"

Quanto tempo sua empresa aguenta ficar sem sistema?

Em 2024, uma clínica de imagem de médio porte na região metropolitana de São Paulo perdeu o servidor principal numa terça-feira à tarde. Não foi ataque, não foi incêndio: uma falha simples na controladora do storage levou junto o banco de dados de exames, a fila de laudos e o prontuário eletrônico. A equipe voltou ao papel e ao telefone em poucos minutos, mas a operação ficou comprometida por quase três dias enquanto o ambiente era reconstruído do zero. Pacientes remarcados, receita interrompida, reputação arranhada.

Cenários assim são mais comuns do que parece. Estudos recorrentes do setor, como os relatórios da Uptime Institute e da Veeam, mostram que mais de 70% das empresas já passaram por uma interrupção não planejada que afetou negócios críticos. O que separa um percalço de um desastre não é a causa, e sim o plano de recuperação de desastre (Disaster Recovery, ou DR) que estava pronto, ou não, antes do problema acontecer.

Se a sua empresa ainda trata DR como "um problema de grande empresa", vale revisitar essa ideia. Pequenas e médias empresas são justamente as que mais sofrem com paradas longas, com menos redundância e menos fôlego financeiro para absorver o impacto.

O que é recuperação de desastre em TI

Recuperação de desastre (Disaster Recovery) é o conjunto de processos e ferramentas que permite restabelecer os sistemas e dados de uma empresa após uma interrupção. Pode ser uma falha de hardware, um ataque de ransomware, um desligamento elétrico, um erro humano ou um evento físico como alagamento e incêndio.

É importante não confundir DR com backup. Backup é a cópia dos dados. DR é a capacidade de voltar a operar usando esses dados dentro de um tempo aceitável. Uma empresa pode ter backup perfeito e ainda assim ficar dias parada se não tiver um plano de como restaurar, em que ordem, em qual infraestrutura e quem faz o quê.

DR também não é o mesmo que alta disponibilidade (HA), embora se complementem. Alta disponibilidade evita a parada por meio de redundância, com clusters, balanceamento e réplicas. DR assume que a parada aconteceu e trata de voltar rápido. Uma boa estratégia combina as duas: HA para reduzir a ocorrência, DR para limitar o estrago quando HA não dá conta.

Por que PMEs também precisam

Há um mito antigo de que DR é coisa de banco e datacenter. A realidade de 2026 é outra:

Tudo virou digital. NF-e, SPED, prontuário eletrônico, pagamento, atendimento. Parar o sistema é parar a operação.
Ransomware mirou PMEs. Ataques automatizados varrem faixas de IP e criptografam servidores de pequenas empresas exatamente porque elas costumam ter defesa mais fraca.
LGPD cobra continuidade. A lei exige medidas técnicas e organizacionais para proteger dados pessoais, o que inclui capacidade de recuperação.
Custo de parada subiu. Com margens apertadas, 8 horas paradas podem consumir o lucro do mês.

Pequena empresa não precisa do DR de um banco, mas precisa de um DR compatível com o seu risco.

RPO e RTO: as duas métricas que definem o seu DR

Toda estratégia de recuperação gira em torno de duas perguntas: quanto dado posso perder? e quanto tempo posso ficar parado? As respostas têm nomes.

RPO (Recovery Point Objective)

O RPO é o volume máximo de dado que a empresa aceita perder em caso de desastre, medido em tempo. Um RPO de 1 hora significa que, no pior cenário, você perde no máximo 1 hora de trabalho, o equivalente a ter backups (ou réplicas) de no máximo 1 hora atrás. Quanto menor o RPO, mais frequente e cara a replicação precisa ser.

RTO (Recovery Time Objective)

O RTO é o tempo máximo aceitável entre a parada e o retorno à operação. Um RTO de 4 horas significa que, a partir do momento em que o sistema cai, a empresa tem 4 horas para tudo voltar a rodar: restaurar, reconfigurar, validar, liberar. Quanto menor o RTO, mais automática e redundante precisa ser a infraestrutura de recuperação.

A diferença entre os dois parece pequena, mas é real: RPO fala de dado perdido, RTO fala de tempo parado. Você pode ter RPO zero (réplica síncrona, nada se perde) e ainda assim RTO de horas (porque o failover é manual e demora). Ou o contrário: RTO de minutos (cluster automático) com RPO de algumas horas (snapshot noturno).

Tabela de referência por tipo de sistema

Nem todo sistema merece o mesmo tratamento. Um atalho prático é classificar os sistemas por criticidade e definir RPO/RTO diferentes para cada um:

Sistema	Criticidade	RPO sugerido	RTO sugerido	Estratégia típica
ERP / financeiro	Alta	15 min – 1 h	1 – 4 h	Réplica + failover para nuvem
E-mail e colaboração	Alta	1 h	1 – 2 h	Serviço em nuvem (Microsoft 365, Google Workspace)
Banco de dados de vendas	Média-alta	1 – 4 h	4 – 8 h	Snapshot frequente + restore testado
Site institucional	Média	24 h	4 – 8 h	Backup diário + redeploi automático
Arquivo morto / backups antigos	Baixa	24 h	24 – 72 h	Cópia offline, restauração sob demanda

Os números acima são pontos de partida, não regras. O ideal é definir os seus a partir de uma conversa real sobre impacto de negócio: quanto cada hora parada custa em receita, em multa, em reputação.

Como montar um plano de recuperação de desastre em 6 passos

Um plano de DR não precisa ser um documento de 200 páginas. Precisa ser claro, testado, e estar acessível quando tudo der errado. Um roteiro enxuto para PMEs:

Inventário e classificação. Liste os sistemas, donos, dependências e dados. Classifique por criticidade (alta, média, baixa) e atribua RPO e RTO a cada um.
Definição da arquitetura de recuperação. Escolha onde e como cada sistema volta: servidor de contingência local, nuvem (IaaS), serviço SaaS substituto ou restauração de backup. Quanto menor o RTO, mais automatizado precisa ser.
Backup e replicação alinhados ao RPO. A frequência de backup/snapshot deve respeitar o RPO declarado. Backup noturno não serve para RPO de 1 hora.
Documentação do runbook. Um passo a passo de execução: quem faz o quê, em que ordem, com quais credenciais e por quais ferramentas. Inclua contatos de fornecedores e suporte.
Teste real, pelo menos duas vezes por ano. Simule a queda de um sistema crítico e meça o tempo de retorno. Sem teste, o plano é uma hipótese. Empresas que testam descobrem, em média, que boa parte dos planos tem falhas silenciosas.
Revisão periódica. Sistemas, pessoas e fornecedores mudam ao longo do tempo. Revise o plano a cada 6 a 12 meses ou após qualquer mudança relevante de infraestrutura.

Um ponto frequentemente esquecido: o plano precisa estar acessível fora do ambiente que pode cair. Um runbook que só existe num wiki interno que morreu junto com o servidor não serve para nada. Mantenha uma cópia offline ou em nuvem separada.

Alta disponibilidade: o complemento que evita o desastre chegar

Alta disponibilidade (HA) é a camada que tenta impedir que a parada aconteça em primeiro lugar. Para PMEs, HA costuma ser viável com custo razoável graças à virtualização e à nuvem:

Cluster de hypervisores (Proxmox, VMware, Hyper-V) com armazenamento compartilhado. Se um nó cai, a máquina virtual reinicia em outro em segundos.
Réplica de banco de dados (primary/replica). A leitura e o failover passam para a réplica se o primário falhar.
DNS e CDN para o site. Distribuem o tráfego e absorvem picos e indisponibilidades parciais.
Serviços críticos em SaaS (e-mail, armazenamento, autenticação). A redundância fica por conta do provedor, sem custo de infraestrutura própria.

A regra prática: HA reduz a frequência do problema, DR limita o tamanho do estrago. Investir só em uma das duas deixa a empresa exposta. O equilíbrio entre as duas é o que se chama de continuidade de negócio.

Como a Work Technology pode ajudar

Montar um plano de recuperação de desastre do zero, ou revisar um que nunca foi testado, é o tipo de trabalho que rende mais quando feito com quem já fez várias vezes. A Work Technology estrutura a continuidade da sua empresa de ponta a ponta:

Diagnóstico de continuidade. Mapeamos sistemas, dependências e pontos únicos de falha, e definimos RPO/RTO por sistema junto com a sua equipe.
Implementação de backup e replicação alinhados ao RPO, com cópias local, offsite e imutável.
Arquitetura de alta disponibilidade. Clusters de servidores, réplicas e failover para reduzir paradas.
Plano de DR documentado com runbook claro, contatos e prioridades de restauração.
Testes de recuperação periódicos sob contrato, com relatório de tempo gasto e correções.
Adequação à LGPD. Mantemos a rastreabilidade e a retenção que a fiscalização espera.

Não espere o primeiro desastre para descobrir o que faltava. Fale com a Work Technology e agende uma avaliação da sua estratégia de recuperação. Com RPO e RTO definidos e um plano testado, a operação volta no ar no tempo certo, e o que poderia ser um prejuízo fica num percalço.