Quase todo mundo tem backup. Quase ninguém tem backup que funciona, e a diferença entre as duas frases só aparece no pior dia possível, quando já não dá para consertar.
Uma cópia de arquivos não é backup. Backup é uma cópia que pode ser restaurada, e quatro condições separam uma coisa da outra.
1. Precisa estar em outro lugar
Backup guardado no mesmo servidor que o site protege contra uma única coisa: você apagar um arquivo sem querer. Não protege contra invasão, porque quem entrou tem acesso aos dois. Não protege contra falha de disco, porque os dois estão no mesmo disco. Não protege contra o provedor suspender a conta, porque a suspensão leva tudo junto.
A regra clássica da área continua valendo: três cópias, em dois tipos de mídia, com uma fora do local. Para a maioria dos sites, isso se traduz em algo simples: o site, um backup no provedor e um backup num serviço de armazenamento separado.
2. Precisa incluir o banco de dados
Esse erro é específico e muito comum em WordPress. Alguém baixa os arquivos por FTP, guarda numa pasta e considera a tarefa cumprida.
Mas os arquivos são só o tema, os plugins e as imagens. Todo o conteúdo está no banco: posts, páginas, comentários, usuários, configurações. Um backup só de arquivos restaura um site vazio, com a aparência certa e nenhum texto dentro.
As duas partes precisam ser copiadas juntas, e no mesmo momento. Arquivos de hoje com banco da semana passada produzem um site inconsistente.
3. Precisa ter idade variada
Manter apenas o backup mais recente resolve o desastre visível e não resolve o invisível.
Se o site foi comprometido e ninguém percebeu por dez dias, o backup de ontem contém o problema. Se uma alteração quebrou algo discretamente há três semanas, o backup de ontem contém a quebra.
Uma política razoável mantém versões diárias recentes, semanais do último mês e mensais de alguns meses. Ocupa mais espaço e é a única forma de voltar para antes de um problema que você descobriu tarde.
4. Precisa ter sido testado
Esta é a condição que quase ninguém cumpre, e é a que decide.
Um backup nunca restaurado é uma hipótese. Arquivos corrompidos, exportações incompletas, senhas de banco que mudaram, dependências que não existem mais: tudo isso só aparece na tentativa de restauração, que é exatamente o momento em que você tem menos tempo e mais pressão.
Teste pelo menos uma vez. Restaure num ambiente separado, abra o site, confira se o conteúdo está lá e se funciona. Uma hora gasta hoje vale por todas as que você não vai gastar no dia do incidente.
As perguntas que revelam o estado real
Quatro perguntas, respondidas honestamente, dizem se o seu backup é real:
- Onde está a cópia mais recente e quando foi feita? Se a resposta for uma estimativa, o backup não é monitorado.
- Ela inclui o banco?
- Se o servidor sumisse agora, você teria acesso a ela?
- Quanto tempo levaria para o site voltar? Essa resposta é o seu tempo real de recuperação, e vale saber antes de precisar.
O que dá para aceitar perder
Há uma decisão que raramente é tomada de forma explícita: quanto de trabalho você aceita perder?
Se o backup é diário, você aceita perder até um dia. Para um site institucional, isso costuma ser tranquilo. Para uma loja com pedidos entrando, um dia de pedidos perdidos é um problema sério, e a frequência precisa ser outra.
A frequência do backup deveria sair dessa conta, não do que vem configurado por padrão.
O mínimo que resolve
Para a maioria dos sites, um arranjo simples já muda o cenário completamente: backup automático diário incluindo arquivos e banco, retenção de pelo menos trinta dias, uma cópia fora do servidor e um teste de restauração por ano.
Nada disso é caro nem complicado. O que custa caro é descobrir, no dia errado, que a pasta que você chamava de backup tinha só metade das coisas.
Se quiser um ambiente com backup automático já incluído e restauração assistida, veja os planos da StayCloud.
