# Disaster recovery WordPress: O plano em 4 camadas
Disaster recovery no WordPress é o plano que define em quanto tempo o site volta ao ar e quanto dado você aceita perder. Segundo a documentação do WP-CLI (2024), o comando wp db import restaura o banco sem o limite de 30 s do PHP. Backup é só a primeira das 4 camadas. Sem teste de restauração, não há recuperação garantida.
Disaster recovery é o conjunto de procedimentos que tira um site WordPress de uma falha grave e o devolve ao ar em tempo previsível. Não é o mesmo que backup: o backup é a cópia, enquanto o disaster recovery é o processo inteiro de detectar, restaurar e validar. A diferença aparece na pior hora possível, quando o disco falha ou o site é invadido e a equipe descobre que a cópia nunca foi testada. Um plano de disaster recovery responde a duas perguntas antes do desastre acontecer: quanto tempo o site pode ficar fora e quanto conteúdo pode sumir. Quem cuida de muitos sites trata isso como parte da gestão de sites WordPress, não como tarefa avulsa.
---
## O que é disaster recovery: RTO, RPO e as 4 camadas
Disaster recovery no WordPress se mede por dois números: o RTO (tempo máximo até o site voltar ao ar) e o RPO (perda máxima de dados aceitável). Um blog institucional tolera RTO de 4 horas e RPO de 24 horas; uma loja em horário de pico não aceita nem 15 minutos de queda.
Definir esses dois valores antes de escolher ferramenta é o que separa um plano de disaster recovery de uma coleção de backups soltos. A partir do RTO e do RPO, o plano se organiza em 4 camadas complementares que cobrem desde a cópia dos dados até o roteiro de quem executa a recuperação.
Disaster recovery WordPress: as 4 camadas e o papel de cada uma
Camada
Função no plano
Falha que cobre
Backup
Cópia versionada de arquivos e banco
Exclusão acidental, update quebrado
Restauração testada
Voltar a cópia em ambiente real
Backup corrompido ou incompleto
Monitoramento
Detectar a queda em minutos
Site fora do ar sem aviso
Runbook
Roteiro de quem faz o quê
Demora por falta de processo
## Camada 1: Backup que cobre arquivos e banco
A primeira camada do disaster recovery é um backup completo, e a falha mais comum aqui é guardar só o banco de dados e esquecer os arquivos. O banco tem os textos e configurações, mas as imagens, PDFs e uploads dos clientes vivem em wp-content/uploads, fora dele.
Um backup automático do banco sem incluir wp-content + restauração após invasão devolve um site sem nenhuma imagem. Ferramentas como UpdraftPlus, BackWPup e o WP-CLI cobrem os dois lados quando configuradas para banco e arquivos juntos. A frequência segue o RPO: loja ativa pede backup incremental de hora em hora, site estático aceita diário. Vale revisar a frequência de backup sempre que o volume de conteúdo muda, porque um RPO de 24 horas num site que publica 10 vezes ao dia já é cópia velha demais.
## Camada 2: Restauração testada, não só backup guardado
A segunda camada do disaster recovery é a que quase todo mundo pula: restaurar o backup num ambiente real antes da emergência. Um backup que nunca foi restaurado + falha de disco real = arquivo corrompido descoberto só na hora errada, com o RTO já estourado.
Disaster recovery sem teste de restauração é fé, não processo. O lugar certo para esse teste é um ambiente de staging, uma cópia isolada onde dá para subir o backup e conferir se o site abre, se o login funciona e se as imagens carregam. A gente vê no suporte da FULL que boa parte dos sites com backup ativo nunca passou por um teste de restauração completo, e é nesse grupo que a recuperação demora horas a mais. O passo a passo de como restaurar o WordPress a partir do backup deve ser ensaiado pelo menos uma vez por trimestre, não improvisado no susto.
## Camada 3: Monitoramento para detectar a queda em minutos
A terceira camada do disaster recovery é o monitoramento, porque um RTO baixo é impossível se ninguém percebe a queda. Monitoramento de uptime ausente + queda de madrugada = horas de site fora do ar antes de alguém reclamar pela manhã.
Um serviço de monitoramento de uptime testa a URL a cada 1 a 5 minutos e dispara alerta por e-mail ou WhatsApp no primeiro erro 500. Soma-se a isso o monitoramento de integridade: plugins como o All in One Security registram alterações suspeitas de arquivo, e o Google Search Console avisa quando marca o site como comprometido. A telemetria do Cloudflare, que observa tráfego e disponibilidade na borda da rede, complementa esse sinal ao mostrar se a queda é do servidor ou da camada de DNS. Sem essa camada, o cronômetro do RTO só começa a contar quando um cliente liga reclamando.
## Camada 4: Runbook e o custo real de cada hora parada
A quarta camada do disaster recovery é o runbook: um roteiro curto que diz quem restaura, de qual backup e em que ordem, transformando pânico em checklist. Cada hora de site parado tem custo: uma loja que fatura R$ 2.000 por dia perde cerca de R$ 85 por hora útil fora do ar.
O runbook precisa apontar a origem de cada backup, a ordem de restauração (banco antes ou depois dos arquivos) e o caminho de fallback, sem contar a queda de ranking quando o Googlebot encontra erro 500 repetido. Aqui mora o detalhe técnico que doc oficial não cobre: a restauração de um banco acima de 1 GB pelo UpdraftPlus em PHP com max_execution_time padrão de 30 s costuma estourar o timeout no meio do import e deixar a tabela cortada. Nesses casos, restaurar por WP-CLI com wp db import ignora o limite do PHP-FPM e conclui o processo inteiro. Esse roteiro vive junto da recuperação de site hackeado por backup, porque invasão é o cenário onde o runbook mais salva tempo.
## Plano de gestão FULL: Disaster recovery por r$ 85 ao mês por site
Montar e manter as 4 camadas de disaster recovery em vários sites de forma manual consome horas que a maioria das agências não tem. O plano PRO da FULL custa R$ 849,90 por mês e cobre até 10 sites, o que dá cerca de R$ 85 por site.
Esse valor inclui backup automático, restauração assistida e painel único de monitoramento de uptime. A gente vê no suporte da FULL que o gargalo raramente é a ferramenta de backup, e sim a falta de um processo testado rodando em todos os sites ao mesmo tempo. Conhecer o painel de gestão de sites WordPress ajuda a entender como centralizar isso. Veja os detalhes em FULL.services/planos.
Perguntas frequentes sobre disaster recovery no WordPress
Qual a diferença entre backup e disaster recovery no WordPress?
Backup é a cópia dos dados; disaster recovery é o processo inteiro de voltar ao ar. O backup é a camada 1 de um plano que tem mais três: restauração testada, monitoramento e runbook. Um site pode ter backup diário e ainda assim levar 6 horas para voltar se ninguém nunca testou a restauração nem sabe quem executa o processo.
É possível ter disaster recovery sem testar a restauração?
Não. Sem teste de restauração você tem backup, não disaster recovery. Um backup só vira recuperação quando foi restaurado pelo menos uma vez num ambiente de staging e o site abriu com imagens e login funcionando. A gente vê no suporte que boa parte dos backups corrompidos só é descoberta na hora da emergência, exatamente porque nunca foram testados antes.
Por que um backup sozinho não protege contra uma invasão?
Porque a invasão pode estar dentro do próprio backup. Se o malware entrou há duas semanas e o backup é diário, restaurar a cópia mais recente devolve o site já infectado. Um plano de disaster recovery guarda versões de várias datas e inclui varredura antes de restaurar, com plugins como o All in One Security. Restaurar sem checar a data limpa apenas reinfecta o site.
Quanto tempo um plano de disaster recovery economiza numa queda?
Um runbook testado costuma cortar o RTO de horas para minutos. Sem roteiro, a equipe perde tempo procurando qual backup usar e em que ordem restaurar; com runbook, a restauração por WP-CLI de um banco de 1 GB termina em poucos minutos. Cada hora parada tem custo: uma loja de R$ 2.000 por dia perde cerca de R$ 85 por hora útil fora do ar.
O que são RTO e RPO num plano de disaster recovery?
RTO é o tempo máximo até o site voltar; RPO é a perda máxima de dados aceitável. Um RTO de 15 minutos exige restauração automatizada e monitoramento ativo; um RPO de 1 hora exige backup incremental de hora em hora. Definir esses dois números antes de escolher ferramenta é o primeiro passo de qualquer plano de disaster recovery sério.
## Próximos passos para blindar seu WordPress
Disaster recovery deixa de ser teoria quando as 4 camadas rodam juntas: backup que cobre arquivos e banco, restauração testada em staging, monitoramento que detecta a queda em minutos e um runbook que tira a equipe do improviso. O erro recorrente é parar na camada 1 e chamar isso de plano. Comece definindo seu RTO e RPO, depois teste uma restauração completa ainda hoje. Para continuar aprendendo, o FULL Academy reúne os tutoriais de backup, restauração e gestão num só lugar. O plano só existe de verdade depois do primeiro teste de restauração bem-sucedido.
Legenda: um painel único de uptime e backup é o que torna o disaster recovery viável em vários sites ao mesmo tempo.