Plano de recuperação
Um backup não é um plano de recuperação
Backups importam, mas recuperação precisa de ownership, testes de restauro, acessos, dependências, base de dados, DNS, ficheiros e decisão clara.
Um backup não é um plano de recuperação enquanto ninguém souber o que cobre, como restaurar, quem decide e como validar o site recuperado.
Backups só contam se o restauro for compreendido
Um backup não é um plano de recuperação enquanto a equipa não consegue explicar o que está incluído, onde vive, como se restaura, quem pode aprovar a recuperação e como o site recuperado será validado. Sem isso, um backup é apenas uma suposição com data.
Isto pesa mais quando WordPress, WooCommerce ou PHP à medida já estão sob pressão. Um backup pode incluir ficheiros mas não base de dados. Pode incluir base de dados mas não uploads. Pode depender de um painel de alojamento sem acesso, de uma conta remota sem owner ou de uma rotina que falhou silenciosamente há semanas.
A primeira verificação deve ser prática: ficheiros em produção, base de dados, uploads, configuração, DNS, SSL, cron jobs, envio de email, callbacks de pagamento, API keys e definições de servidor necessárias para o site correr. Se essas peças estão divididas por fornecedores, o caminho de restauro precisa de mapa antes do incidente.
É por isso que suporte de alojamento gerido deve tratar backups como parte do ownership operacional, não como checklist. A pergunta útil não é se existe backup. É se a recuperação pode ser feita com confiança.
A recuperação falha na camada das dependências
Muitas recuperações falham porque o ficheiro de backup é apenas uma dependência. Um site pode restaurar com sucesso e continuar partido se o DNS aponta para outro lado, o SSL falta, a versão de PHP mudou, permissões alteraram, cron não corre, cache ficou stale, email está bloqueado ou callbacks de pagamento voltam para o URL errado.
Em WooCommerce, isto é ainda mais sensível. Encomendas, stock, contas de cliente, estados de pagamento, subscrições, webhooks e emails podem mudar entre o timestamp do backup e o incidente. Restaurar às cegas pode perder dados ou criar registos comerciais contraditórios.
Um plano de recuperação deve dizer que tipo de incidente cobre: ficheiros apagados, update falhado, plugin comprometido, corrupção de base de dados, falha de servidor, rollback de migração, erro de DNS ou incidente de checkout. Cada cenário tem um caminho de restauro e validação diferente.
Quando a recuperação toca código, alojamento e workflow de negócio ao mesmo tempo, suporte de programação web, revisão de segurança e acesso ao servidor precisam de estar no mesmo plano. Caso contrário, a equipa restaura uma camada e continua a perseguir falhas noutra.
Transformar restauro num processo de suporte testado
Um processo de recuperação suportável não precisa de documentação enterprise pesada. Precisa de notas claras: origem do backup, retenção, owner de acessos, ordem de restauro, downtime esperado, tratamento da base de dados, passos de DNS ou SSL, checklist de validação e ponto de decisão para abandonar a recuperação e escolher outro caminho.
Testar nem sempre significa restaurar produção. Pode significar restaurar em staging, confirmar que arquivos abrem, verificar dumps de base de dados, confirmar storage externo, documentar acesso ao painel e testar um fluxo representativo. O essencial é trocar esperança por evidência.
Para agências, este registo é comercialmente útil. Explica o que está coberto, o que não está, o que depende de terceiros e o que deve ser corrigido antes do próximo incidente. Também evita que cada falha se transforme numa investigação nova sob pressão.
Um próximo passo prático é registar o estado atual de backup e recuperação num brief técnico. A partir daí, o trabalho pode tornar-se limpeza de alojamento, verificação de backups, hardening ou ritmo de suporte mensal com ownership de recuperação incluído.
Conclusão prática
- Não tratar a existência de backup como prova de que a recuperação vai funcionar.
- Mapear ficheiros, base de dados, uploads, DNS, SSL, cron, email e integrações antes do incidente.
- Definir quem decide o restauro e como o site recuperado será validado.
- Testar parte suficiente do caminho de restauro para substituir suposições por evidência.