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.

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 pública 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

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.