Um plano de recuperação de desastre não é um documento para crises de nível cinematográfico. É o conjunto de procedimentos que permite à tua agência restaurar qualquer site do portfólio em tempo definido, com perda de dados mínima e comunicação estruturada ao cliente. A maioria das agências não tem este plano — e descobre isso exactamente quando mais precisava dele.
RTO e RPO: as duas métricas que definem o plano
Antes de criar qualquer procedimento, precisas de definir dois números por tipo de site:
- RTO (Recovery Time Objective): quanto tempo máximo pode o site estar em baixo? Para um site institucional de uma PME, pode ser 4-8 horas. Para uma loja WooCommerce activa, pode ser 1-2 horas. Para um portal de serviços críticos, minutos.
- RPO (Recovery Point Objective): qual a perda de dados máxima aceitável? Para um site de conteúdo, 24 horas pode ser aceitável. Para uma loja WooCommerce, perder encomendas das últimas 2 horas pode já ser inaceitável — RPO de 1 hora ou menos.
O RTO e RPO determinam a frequência de backups necessária e os investimentos em infraestrutura de recuperação. Um site com RTO de 1 hora precisa de processo de restauro praticado e testado — não de um ficheiro de backup que nunca foi aberto.
Os cinco cenários de desastre mais comuns em WordPress
1. Falha de alojamento (servidor down)
Causa: falha de hardware, problemas de rede, ataque DDoS ao datacenter, manutenção não planeada do hosting provider.
Recuperação: migrar o site para servidor alternativo. Pressupõe ter backups externos (não no mesmo servidor que falhou) e acesso a um servidor de contingência.
Tempo típico de recuperação: 2-6 horas se os backups estiverem externos e actualizados.
2. Site comprometido (hack/malware)
Causa: vulnerabilidade explorada em plugin, tema ou core desactualizado.
Recuperação: restaurar a partir de um backup anterior à comprometação (identificar quando ocorreu), remover malware, corrigir a vulnerabilidade, alterar todas as passwords.
Armadilha: restaurar de um backup que já contém o malware. É preciso identificar a data de comprometação antes de escolher o ponto de restauro.
3. Erro fatal após update
Causa: incompatibilidade entre componentes após actualização.
Recuperação: rollback para o backup feito antes do update. Se havia ambiente de staging, não chega a produção.
Tempo típico de recuperação: 30-60 minutos com backup recente e processo de rollback praticado.
4. Eliminação acidental de dados
Causa: colaborador ou cliente eliminou conteúdo crítico (posts, produtos, páginas, dados de formulário).
Recuperação: restauro parcial de base de dados. Mais complexo do que restauro completo — requer extrair dados específicos do backup sem sobrescrever o resto.
5. Corrupção de base de dados
Causa: plugin mal codificado, falha durante uma escrita, execução interrompida de migration.
Recuperação: repair de tabelas específicas (se possível) ou restauro completo de base de dados a partir de backup.
Como estruturar o plano de recuperação por tipo de site
Um plano de recuperação não precisa de ser um documento de 50 páginas. Precisa de ser utilizável sob pressão — curto, claro e testado:
Template por site
- Identificação do site: URL, cliente, responsável técnico
- RTO / RPO definidos: acordados com o cliente e documentados
- Localização dos backups: onde estão, como aceder, frequência e retenção
- Procedimento de restauro: passo a passo para restauro completo e parcial — testado e com tempo estimado validado
- Acessos de emergência: hosting, FTP, base de dados, wp-admin — centralizados num gestor de passwords da agência
- Canal de escalada: quem contactar e em que ordem quando ocorre um incidente
- Template de comunicação ao cliente: mensagem inicial e updates durante recuperação
Restore drills: porque os backups que nunca foram testados não são backups
Um restore drill é um teste controlado do processo de recuperação: pegar num backup real e restaurar o site num ambiente de teste, validando que o resultado está funcional e que o tempo de recuperação é dentro do RTO definido.
Os restore drills revelam problemas que a existência do backup não garante:
- Ficheiro de backup corrompido ou incompleto
- Processo de restauro mais lento do que o RTO definido
- Dependências externas (APIs, serviços de email) que não funcionam no ambiente de restauro
- Falta de acessos ou permissões necessários para o restauro
A frequência recomendada para restore drills é mensal para sites críticos (e-commerce, portais de serviços) e trimestral para sites institucionais.
O plano de comunicação ao cliente durante um desastre
Tão importante como a recuperação técnica é a gestão da comunicação. O cliente precisa de:
- Ser notificado proactivamente — não descobrir o problema antes de ti
- Receber actualizações regulares durante a recuperação (a cada 30-60 minutos)
- Receber confirmação de resolução com contexto claro
- Receber post-mortem 24-48h depois com causa raiz e medidas preventivas
Para mais detalhe sobre comunicação de incidentes, ver o artigo sobre gestão de incidentes WordPress.
Queres backups testados e plano de recuperação gerido para o teu portfólio?
A manutenção WordPress da Vuvo inclui backups automáticos, restore drills mensais documentados e plano de escalada para incidentes.
Conhecer o serviço