Ter backup não é o mesmo que restaurar

Antes de apagar qualquer coisa de um site que eu tinha acabado de assumir, fui conferir o histórico de versões. Queria ter uma cópia de cada página, do jeito que estava, antes de tocar em qualquer configuração. Abri o painel, e havia uma lista de datas, como qualquer ferramenta de backup mostra. Cliquei na mais recente para confirmar que o conteúdo estava ali dentro.

Não estava. A lista existia. O conteúdo, não. Era a aparência de um histórico, sem nada dentro dele. Qualquer exclusão a partir daquele ponto seria definitiva, sem volta nenhuma, e a tela nunca avisou isso.

Essa é a pergunta que decide se o seu site tem backup de verdade, e a resposta não está na tela que diz “backup concluído”. Está num teste que muito poucos donos de site fazem: pegar a cópia, tentar abri‑la de verdade, num lugar separado do site original, e ver se o que volta é o que deveria voltar. Até esse teste existir, o que você tem não é backup. É uma crença sobre backup, e as duas custam o mesmo em paz de espírito até o dia em que uma delas precisa funcionar.

O que “ter backup” realmente significa

Existe uma distância entre dois estados que a maioria confunde: o estado em que algo foi aceito pelo sistema, e o estado em que esse algo foi de fato processado e está disponível para uso. Um painel de hospedagem que mostra “backup concluído às 3h da manhã” está te informando apenas o primeiro estado. Ele aceitou o pedido de cópia e não encontrou erro durante a gravação. Isso é bem diferente de garantir que o arquivo gravado abre, que ele contém o que deveria conter, e que o processo de trazê‑lo de volta para o ar funciona do início ao fim.

A maioria das interfaces de backup informa exatamente isso que é fácil de medir do lado de dentro, que o processo rodou sem travar, e nunca aquilo que importa de verdade para quem depende do site, que é se ele volta. São perguntas diferentes, respondidas por processos diferentes, e confundir as duas é o motivo pelo qual tanta gente só descobre que não tinha backup no exato momento em que precisava dele.

Isso não é falha de um fornecedor incompetente. É o desenho normal da maioria das ferramentas de backup, que foram construídas para avisar sobre falha de gravação, não sobre falha de restauração. Testar se o arquivo volta exige um passo extra, que consome tempo e espaço, e que a maioria das configurações padrão simplesmente não faz sozinha. Alguém precisa decidir fazer esse teste, de propósito, fora do fluxo automático.

Teste de restauração

Processo de pegar uma cópia de segurança já feita e efetivamente recuperar o site a partir dela, num ambiente separado do original, verificando se o conteúdo, a estrutura e as funções essenciais voltam a funcionar. Diferente de confirmar que o backup “existe”: o teste de restauração confirma que ele serve para alguma coisa quando for de fato necessário.

O número que mostra a distância entre ter e conseguir

Essa distância entre ter uma cópia e conseguir usá‑la não é um problema raro, nem um problema exclusivo de quem administra o próprio site sem nenhuma ajuda técnica. Uma pesquisa de 2026 com 319 administradores, desenvolvedores e donos de sites em WordPress, feita pela Melapress, achou que apenas 27,9% deles tinham algum plano de recuperação depois de um incidente de segurança.² Não é a minoria técnica que falha nisso. É a maioria, incluindo gente que mexe no próprio site todos os dias.

Sobe um nível na cadeia e o quadro não melhora como seria de esperar. Uma pesquisa de 2024 com 1.000 arquitetos de nuvem e executivos de tecnologia sênior, feita pela Cockroach Labs, achou que menos de um terço dessas empresas, com equipe técnica dedicada e orçamento de infraestrutura, faz qualquer tipo de teste de failover, que é o nome técnico para simular uma pane e verificar se o plano de recuperação realmente funciona.³

No topo da cadeia, onde o incidente já aconteceu e o backup devia estar sendo usado de verdade, a Sophos mediu em 2025, numa pesquisa com 3.400 líderes de tecnologia e segurança em 17 países atingidos por ataques de ransomware no ano anterior, que só 54% conseguiram restaurar os próprios dados a partir de backup, a taxa mais baixa dos últimos seis anos medidos pela mesma pesquisa.¹

Três números, três públicos diferentes, a mesma forma de falha: quem tem equipe, orçamento e motivo forte para testar continua, na maioria, não testando, até o dia em que o teste deixa de ser opcional e passa a ser a única coisa que decide se o site volta.

Por que a tela confunde você, e não por acidente

Parte do motivo pelo qual tanta gente confia na tela é que a tela foi desenhada para tranquilizar, não para avisar. Um painel que mostra uma lista de datas cria a impressão de profundidade, de que existe um histórico inteiro guardado, pronto para qualquer momento no passado que você precisar. Na prática, a maioria dos planos de hospedagem guarda uma janela limitada, geralmente entre sete e trinta dias, e depois desse prazo a cópia mais antiga é apagada para abrir espaço para a mais nova, sem nenhum aviso de que isso está acontecendo.

Janela de retenção

Período durante o qual um serviço de backup mantém cópias antigas antes de descartá‑las automaticamente para liberar espaço. A maioria dos planos de hospedagem compartilhada opera com janelas entre sete e trinta dias. Passado esse prazo, mesmo um backup que existiu de fato deixa de existir, silenciosamente, sem notificação para quem depende dele.

Isso explica por que o problema raramente aparece logo de cara. Nos primeiros meses depois de configurar um backup automático, qualquer teste improvisado tende a funcionar, porque a cópia é recente e o processo ainda não teve chance de falhar em silêncio. O risco cresce com o tempo, exatamente quando a confiança também cresce, porque ninguém voltou a testar desde a primeira vez. A régua que resolve isso não pede desconfiança constante. Pede repetir o teste de tempo em tempo, e principalmente antes de qualquer mudança que dependa da cópia existir de verdade.

O que a cópia de segurança não resolve sozinha

Vale separar um risco do outro, porque os dois se parecem na superfície e são resolvidos de formas diferentes. Ter uma cópia de segurança protege contra perda de conteúdo, apagão de arquivo, erro de atualização que quebra o site inteiro. Não protege contra um problema de coordenação, que é o que acontece quando mais de uma pessoa mexe no mesmo site sem um processo que avise quem fez o quê.

A cópia de segurança do hospedeiro não previne essa colisão, porque o problema não é perder dados. É dois arquivos corretos, de duas pessoas diferentes, disputando o mesmo lugar sem ninguém avisar o outro. Quando mais de um fornecedor cuida do mesmo site, o defeito mora exatamente nesse espaço entre eles, no que nenhum dos dois estava olhando porque presumia que o outro estava.

A régua prática para quem atua sozinho, sem equipe, é mais simples do que parece: mesmo sem segunda pessoa, qualquer mudança que você fizer no site de um fornecedor para outro, ou numa reformulação grande, merece uma cópia datada do estado anterior, separada do processo automático do hospedeiro. Não porque você vá esquecer o que fez. Porque o próprio processo de mudança pode falhar no meio, e nesse momento você quer o estado anterior disponível, não a promessa de que ele estava “disponível” na tela.

O que muda quando você decide testar

Testar uma restauração custa tempo, e vale a pena dizer isso em voz alta em vez de empurrar o custo para debaixo do tapete. Baixar a cópia, subir num ambiente separado, conferir se o conteúdo abre, se os formulários funcionam, se as imagens carregam, tudo isso consome uma tarde que podia estar sendo usada para atender quem paga. A recomendação de testar periodicamente, que aparece no guia de planejamento de contingência do governo americano para sistemas de informação, não promete que o teste seja rápido. Promete que ele é a única forma de saber se o plano funciona antes do dia em que você precisa saber.⁴

O trade‑off real não é “testar ou não testar”. É decidir com que frequência o seu site muda o suficiente para justificar um novo teste. Um site que não muda há meses pode viver com um teste por ano. Um site em reformulação ativa, com fornecedor novo entrando, merece teste antes de cada mudança estrutural grande, porque é exatamente nesse momento que uma cópia que nunca foi aberta tem mais chance de decepcionar.

Essa lacuna não é privilégio de quem administra site grande. Uma pesquisa de 2016 encomendada pela Nationwide, com 502 pequenos empresários americanos à frente de negócios de até 300 funcionários, achou que 68% deles não tinham nenhum plano de recuperação escrito para o próprio negócio, apesar de quase a metade reconhecer que levaria pelo menos três meses para se recuperar de um desastre sem esse plano.⁵ Quem vive da própria especialidade, sozinho, sem departamento de tecnologia, está exatamente dentro dessa maioria, e o site costuma ser o item mais esquecido dentro de um plano que, na maioria dos casos, nem chega a existir no papel.

“Mas eu já pago um plano com backup incluso”

A objeção que normalmente vem depois dessa resposta é prática: “eu não tenho tempo nem conhecimento técnico para testar restauração”. Isso é verdade para a maioria de quem vive da própria especialidade, e é exatamente por isso que o teste não precisa ser feito toda semana. Precisa ser feito pelo menos uma vez, para você saber como é o processo e quanto tempo ele leva, e de novo antes de qualquer mudança grande no site. O resto do tempo, a cópia existe em segundo plano, e você vive com um risco conhecido em vez de um risco que só aparece no pior momento, quando já virou emergência.

O que fica de pé depois do teste

Um domínio registrado no seu nome já resolve metade do risco que uma plataforma alugada carrega, porque a decisão de manter algo no ar deixa de ser de outra empresa. A outra metade do risco mora dentro do próprio site, na distância entre o que a tela promete e o que a cópia realmente entrega quando alguém tenta usá‑la de verdade.

Uma automação que roda sem travar pode não estar fazendo o que deveria fazer, e um backup que aparece concluído pode não voltar quando for aberto. As duas situações têm a mesma raiz: confiar no sinal de que algo rodou, em vez de confirmar o resultado que ele deveria produzir.

Isso não pede uma rotina nova toda semana. Pede uma pergunta específica, feita antes da próxima vez que alguém for tocar em algo estrutural no seu site: se eu precisasse voltar para o estado de ontem agora mesmo, eu sei que consigo, ou só acho que consigo?

Anderson Chipak

Vinte anos construindo software para sistemas que não podem errar. Hoje assume a operação digital de quem vive da própria especialidade — e escreve sobre o custo de fazer tudo sozinho.

Ver mais publicações