Backup de Site: Estratégias para Nunca Perder seus Dados

Existe uma verdade desconfortável sobre backup que quase ninguém quer encarar: você só descobre se a sua estratégia funciona no pior dia possível, quando o site já caiu e não há mais como voltar atrás. Até esse momento, o backup é uma promessa abstrata, um item marcado na lista de tarefas, uma pasta que você imagina cheia mas nunca abriu. E é exatamente aí que a maioria dos desastres acontece: não por falta de backup, mas por confiar em um backup que nunca foi verificado, que estava incompleto ou que apontava para o mesmo servidor que acabou de pegar fogo.

Este artigo trata backup como aquilo que ele realmente é: uma disciplina de engenharia, não um botão. Vamos passar pelo que compõe uma cópia verdadeiramente completa, pela regra que orienta qualquer estratégia séria, pela diferença entre parâmetros que definem quanto você pode perder e quanto tempo leva para se recuperar, e pelo ponto que quase todo mundo ignora até ser tarde demais. O objetivo é que, ao final, você consiga olhar para o seu próprio site e responder com honestidade: se ele sumisse agora, em quanto tempo e com que perda eu voltaria ao ar?

Por que backup é inegociável#

Sites não morrem por um único motivo, e é justamente a variedade das causas que torna o backup indispensável. Pensar em backup apenas como proteção contra "o servidor pifar" subestima o problema.

A falha de hardware é a ameaça clássica: discos têm vida útil finita, controladoras falham, um datacenter tem um incidente elétrico. Provedores sérios trabalham com redundância, mas redundância de infraestrutura não é backup, e voltaremos a esse ponto.

O erro humano é, na prática, a causa mais frequente e mais subestimada. Alguém apaga a tabela errada, sobrescreve um arquivo de configuração, roda um comando de limpeza no diretório errado ou exclui um plugin sem perceber que ele guardava dados. Nenhuma dessas situações é catastrófica se existe uma cópia recente para restaurar; todas são fatais se não existe.

O update quebrado é outro vilão silencioso. Uma atualização de tema, de plugin, do núcleo do WordPress ou da versão do PHP entra em conflito com algo específico do seu ambiente e o site quebra. Sem um ponto de restauração imediatamente anterior à atualização, você troca uma correção de dez minutos por horas de depuração às cegas.

E há as ameaças maliciosas. Uma invasão pode injetar código, desfigurar páginas ou usar o site para distribuir spam e malware. O caso mais severo é o ransomware, que criptografa seus arquivos e exige pagamento pela chave. Contra ransomware, o backup deixa de ser conveniência e vira a única alternativa real ao resgate, com uma ressalva importante: se o backup estava acessível a partir do mesmo servidor comprometido, ele provavelmente também foi criptografado. Backup que o atacante consegue alcançar não protege contra atacante.

O que compõe um backup completo#

Um erro comum é copiar apenas os arquivos e achar que o trabalho está feito. Um site dinâmico, como qualquer instalação de WordPress, tem várias camadas, e restaurar só uma delas resulta em um site que não funciona.

Um backup completo cobre quatro componentes:

• Arquivos da aplicação. Todo o conteúdo do diretório do site: núcleo, temas, plugins, e principalmente os uploads (imagens, PDFs, mídia enviada pelos usuários). É a parte mais volumosa e a que mais cresce com o tempo.
• Banco de dados. É aqui que mora o conteúdo real: textos dos posts, páginas, comentários, usuários, configurações de plugins, pedidos de uma loja. Um backup de arquivos sem o banco restaura a estrutura mas perde o conteúdo; um backup do banco sem os arquivos perde as imagens e o código. Os dois são indissociáveis e devem ser capturados em consistência entre si.
• Configurações. Arquivos como o de configuração do WordPress, regras do servidor web, variáveis de ambiente, definições de cron. Sem eles, restaurar é possível, mas remontar o ambiente vira um quebra-cabeça manual.
• E-mails. Muitas vezes esquecido porque parece um serviço à parte, mas se as caixas de e-mail estão hospedadas junto com o site, elas fazem parte do seu patrimônio digital e precisam ter cópia própria. Perder anos de correspondência costuma doer mais do que perder o site.

O ponto crítico aqui é a consistência. O ideal é que os quatro componentes representem o mesmo instante no tempo. Copiar o banco às três da manhã e os arquivos ao meio-dia cria um backup em que um post existe no banco mas sua imagem ainda não foi salva nos arquivos, ou vice-versa. Estratégias sérias fazem o snapshot de forma coordenada.

A regra 3-2-1#

A regra 3-2-1 é o alicerce de qualquer política de backup madura, e resume décadas de aprendizado da indústria em três números:

• 3 cópias dos seus dados. O original em produção conta como uma; você precisa de pelo menos duas cópias adicionais. A lógica é simples: uma única cópia de segurança que falha te deixa a zero.
• 2 mídias ou tipos de armazenamento diferentes. Não adianta manter as três cópias no mesmo disco físico. Diversificar o meio protege contra a falha correlacionada de um tipo específico de armazenamento.
• 1 cópia offsite, ou seja, fisicamente e logicamente separada do servidor de produção. Esta é a regra mais importante e a mais violada. Se o backup mora no mesmo servidor, no mesmo datacenter e sob a mesma conta que o site, um incidente que atinja o servidor, uma invasão que ganhe acesso à conta ou um ransomware podem levar site e backup juntos.

O espírito da 3-2-1 é eliminar pontos únicos de falha. Cada cópia adicional em um meio e local distinto reduz drasticamente a probabilidade de que um mesmo evento destrua tudo. Versões modernas da regra acrescentam um "1" final para uma cópia offline ou imutável — armazenamento que não pode ser apagado nem por quem tem acesso administrativo, justamente a defesa mais eficaz contra ransomware, que ataca tudo que consegue escrever.

Backup full versus incremental#

Entender os tipos de backup ajuda a equilibrar espaço, tempo e segurança.

O backup full (completo) copia tudo, do zero, a cada execução. É o mais simples de restaurar, porque uma única cópia contém o estado inteiro do site. A desvantagem é o custo: consome muito espaço e muita banda, e rodar um full várias vezes ao dia em um site grande é inviável.

O backup incremental copia apenas o que mudou desde a última cópia. O primeiro backup é sempre full; os seguintes registram somente as diferenças. Isso economiza espaço e tempo de forma expressiva e permite frequências muito maiores. O custo aparece na restauração: para reconstruir o estado, é preciso o full de base mais toda a cadeia de incrementais até o ponto desejado. Se um elo da cadeia estiver corrompido, os pontos posteriores ficam comprometidos.

Há ainda o backup diferencial, um meio-termo: cada cópia registra tudo o que mudou desde o último full (não desde a última cópia). Restaurar exige apenas o full mais o diferencial mais recente, simplificando a recuperação ao custo de cópias que vão engordando entre um full e outro.

Na prática, a estratégia usual combina os três: um full periódico como âncora, incrementais frequentes entre eles, e uma retenção que preserve fulls antigos como pontos de recuperação de longo prazo.

Frequência, RPO e RTO#

Duas siglas orientam toda decisão sobre frequência e velocidade de recuperação, e vale entendê-las bem porque elas transformam "faça backup" em uma decisão mensurável.

O RPO (Recovery Point Objective, ou objetivo de ponto de recuperação) responde: quanto de dados você pode se dar ao luxo de perder? Se você faz backup uma vez por dia e o site cai logo antes do próximo backup, você perde até 24 horas de mudanças. Esse é o seu RPO. A frequência do backup precisa ser ditada pela taxa de mudança do site. Um blog institucional que atualiza uma vez por semana tolera um RPO de um dia sem drama. Uma loja virtual que recebe pedidos a cada minuto tem um RPO de 24 horas equivalente a perder um dia inteiro de vendas — inaceitável. Para esse caso, backups de hora em hora, ou replicação contínua do banco, são o mínimo.

O RTO (Recovery Time Objective, ou objetivo de tempo de recuperação) responde: quanto tempo você pode ficar fora do ar? Não adianta ter um backup perfeito de dez minutos atrás se restaurá-lo leva seis horas de trabalho manual. O RTO depende do tamanho dos dados, do método de restauração e, sobretudo, de quão ensaiado é o processo. Uma restauração que já foi testada e documentada leva minutos; uma improvisada no meio da crise leva o dia inteiro.

A decisão prática nasce do cruzamento: quanto o site perde por hora fora do ar e por dado perdido define quanto vale a pena investir em frequência e em automação. Definir RPO e RTO explicitamente, por escrito, é o que separa uma estratégia de um hábito vago.

Automatizado versus manual#

O backup manual — aquele que você lembra de fazer antes de uma mudança grande — tem seu lugar, mas não pode ser a base da estratégia. Ele depende de disciplina humana, e disciplina humana falha exatamente nos períodos corridos, que costumam ser os de maior risco. Um backup que você "faz quando lembra" é, estatisticamente, um backup que não existe no momento em que você mais precisa.

O backup automatizado roda em agenda fixa, sem depender de ninguém lembrar. É a espinha dorsal de qualquer proteção séria. Mas automatizar traz uma armadilha própria: o backup silencioso que falha sem avisar. Um job agendado que parou de rodar há três semanas, um disco de destino que encheu, uma credencial expirada — nada disso aparece até o dia da restauração. Por isso, automação de verdade inclui monitoramento e alerta: toda execução precisa reportar sucesso ou falha, e a ausência de um backup esperado deve disparar um aviso tão alto quanto qualquer outro incidente. Backup automatizado sem monitoramento é uma falsa sensação de segurança.

O bom arranjo combina os dois: automação frequente como base, e o hábito manual de tirar um snapshot pontual imediatamente antes de qualquer mudança arriscada, como uma atualização grande ou uma migração.

Onde guardar, versionamento e retenção#

Já ficou claro que a cópia mais valiosa é a que vive fora do próprio servidor. Armazenamento em nuvem ou em um serviço de storage dedicado, sob uma conta separada da hospedagem, é o destino natural do offsite. O princípio inegociável: o backup não deve ser acessível pelas mesmas credenciais nem residir na mesma máquina que o site protege. Se um atacante que domina o servidor consegue apagar os backups, eles não passam de arquivos convenientemente localizados para serem destruídos junto.

O versionamento é o que transforma backup em uma máquina do tempo. Guardar apenas a cópia mais recente é perigoso: se um problema (uma invasão, uma corrupção de banco, um plugin que corrompe dados) passa despercebido por alguns dias, o backup mais novo já carrega o defeito. Com múltiplas versões preservadas, você volta para antes do problema começar. Manter várias gerações também protege contra o cenário em que o próprio backup mais recente está corrompido.

A retenção define quantas versões e por quanto tempo você guarda. Uma política escalonada equilibra custo e cobertura: manter backups horários dos últimos dias, diários das últimas semanas, semanais dos últimos meses e mensais do último ano. Assim você tem granularidade fina para o passado recente e pontos esparsos, mas de longo alcance, para trás. A retenção certa depende do seu negócio e de eventuais exigências legais de guarda de dados, mas o princípio é: nunca dependa de uma única versão, e não descarte o passado longo cedo demais.

O ponto mais ignorado: testar a restauração#

Aqui está o coração deste artigo, a frase que vale imprimir: um backup que nunca foi restaurado não é um backup, é uma esperança. A imensa maioria das tragédias de perda de dados não acontece por falta de backup — acontece porque o backup existia, mas estava vazio, corrompido, incompleto ou impossível de restaurar, e ninguém descobriu isso antes da hora fatal.

Testar a restauração significa, periodicamente, pegar um backup real e reconstruir o site a partir dele em um ambiente isolado — um servidor de teste, um ambiente de staging, uma máquina descartável. O teste responde às perguntas que só a prática responde: o backup abre? Os quatro componentes estão presentes e consistentes entre si? O site sobe funcional, com conteúdo e imagens no lugar? Quanto tempo o processo levou de verdade — o seu RTO real, não o imaginado? Existe algum passo manual esquecido que trava tudo?

Um bom ritual de teste de restauração inclui: uma cadência fixa (por exemplo, restaurar de verdade uma vez por mês ou por trimestre), a restauração em ambiente separado para não tocar em produção, a validação de que o site funciona de fato e não apenas de que os arquivos existem, e o registro documentado do procedimento, para que a recuperação real não dependa da memória de uma única pessoa sob pressão. Testar a restauração é também o que valida, na prática, o seu RTO: só o cronômetro no ambiente de teste diz quanto tempo você realmente levaria.

Backup não é alta disponibilidade#

Encerramos desfazendo uma confusão que custa caro. Muita gente acredita estar protegida porque o provedor oferece redundância, réplicas ou "alta disponibilidade". São coisas diferentes, e uma não substitui a outra.

A alta disponibilidade existe para manter o site no ar diante de falhas de infraestrutura: se um servidor cai, outro assume; se um disco falha, a réplica continua. Ela combate a indisponibilidade e melhora o RTO para falhas de hardware. Mas a alta disponibilidade replica o estado atual dos dados em tempo real — inclusive os estados ruins. Se você apaga uma tabela por engano, a exclusão é replicada instantaneamente para todas as réplicas. Se um ransomware criptografa os arquivos, a criptografia se propaga. Se um update quebra o banco, o banco quebrado é o que fica disponível, com altíssima disponibilidade.

O backup, ao contrário, preserva estados passados. Ele é a única defesa contra os erros que a alta disponibilidade fielmente replica: exclusão acidental, corrupção lógica, invasão, ransomware, update ruim. Alta disponibilidade responde "meu servidor caiu"; backup responde "meus dados ficaram errados". Um projeto sério de continuidade tem os dois, cada um cobrindo o que o outro não cobre. Confundir os dois é o tipo de engano que só aparece no dia da perda.

Se você chegou até aqui, o próximo passo natural é olhar para as ameaças que tornam o backup tão necessário e fechar as portas antes que elas se abram — vale aprofundar em como blindar seu site contra invasões e vulnerabilidades, porque prevenção e recuperação são as duas metades da mesma proteção.

No fim, a pergunta que resume tudo é aquela do começo: se o seu site sumisse agora, em quanto tempo e com que perda você voltaria? Se a resposta é um encolher de ombros, você não tem uma estratégia de backup — tem uma aposta. Definir o que salvar, seguir a regra 3-2-1, ancorar a frequência no seu RPO, automatizar com monitoramento, versionar com retenção escalonada e, acima de tudo, testar a restauração de verdade: é isso que transforma a aposta em garantia. E garantia, no dia ruim, é a diferença entre dez minutos de susto e o fim do seu negócio.