O que é realmente um backup

Publicado em 2026-09-12 por frfrand

Un archivo guardado no es un backup: lo es un procedimiento probado de recuperación. La regla 3-2-1, las dos preguntas que definen tu estrategia, y por qué un snapshot no siempre alcanza.

Quase todo mundo tem backups. Muito menos gente tem uma restauração testada. A diferença entre essas duas coisas é todo o assunto.

Um arquivo guardado não é um backup. É um arquivo. Ele se torna um backup no dia em que você comprova que pode voltar a partir dele.

As duas perguntas que definem sua estratégia

Antes de escolher a ferramenta, é preciso responder a duas coisas. Elas têm nomes formais e são muito concretas:

Quantos dados você pode perder? Se você faz um backup por dia e a falha ocorre às 23:00, você perde quase um dia de trabalho. Se isso for inaceitável, você precisa de backups mais frequentes ou de registro contínuo.

Quanto tempo você pode ficar parado? Restaurar um banco de dados grande a partir de um despejo pode levar horas. Se o seu negócio não tolerar isso, você precisa de uma réplica pronta para assumir, não apenas um arquivo.

As respostas mudam completamente a solução. E são decisões de negócio, não técnicas: alguém tem que dizer quanto custa perder quatro horas de dados.

A regra 3-2-1

Três cópias dos dados, em dois tipos de suporte diferentes, uma delas fora do local.

Não é superstição: cada parte cobre um modo de falha.

• Três cópias cobre que uma se corrompa sem que ninguém perceba.
• Dois suportes cobre que falhe um disco, ou um tipo inteiro de armazenamento.
• Uma fora cobre o que leva tudo: um incêndio, uma exclusão em massa, uma conta comprometida.

Esse último ponto merece ênfase: se seus backups estão na mesma conta de nuvem que seu servidor, alguém que comprometa essa conta leva as duas coisas. "Fora" significa outro lugar de verdade.

Completo, incremental e diferencial

Completo: tudo, sempre. Simples de restaurar, caro de armazenar.

Incremental: apenas o que mudou desde o backup anterior. Barato. Para restaurar, você precisa do completo mais toda a cadeia de incrementais; se faltar um, não chega.

Diferencial: o que mudou desde o último completo. Ponto médio: para restaurar, você precisa apenas de dois arquivos.

O esquema habitual e sensato: um completo semanal, incrementais diários e retenção de várias semanas.

Um snapshot nem sempre é um backup

Os snapshots de disco são convenientes e têm dois limites que vale a pena conhecer.

Consistência. Um snapshot captura o disco como está, e um banco de dados pode ter gravações pela metade naquele instante. Motores modernos geralmente se recuperam, mas para bancos de dados o correto é usar a própria ferramenta (pg_dump, ou uma cópia física coordenada), que garante um estado consistente.

Localização. Um snapshot geralmente vive na mesma infraestrutura que o disco. Cobre "apaguei uma tabela", não cobre "perdi a conta".

A parte que quase ninguém faz

Testar a restauração. Completa, em um servidor limpo, com cronômetro.

A primeira vez sempre falta algo: uma extensão do banco que não estava instalada, uma variável de ambiente, uma permissão, um arquivo enviado por usuários que não estava no backup porque ninguém se lembrou de incluí-lo.

É muito melhor descobrir isso numa terça-feira tranquila do que durante um incidente.

Agende uma vez por trimestre. E escreva o procedimento: quem tiver que restaurar pode não ser quem montou o sistema.

Na ArduMaker, cada VPS tem backup completo periódico, a quente, armazenado em um host diferente daquele em que o VPS roda e verificado com seu hash, com instruções de restauração ao lado. Mas o teste de restauração continua sendo um bom hábito, sempre.