Backup ou snapshot: qual usar em cada caso

Os dois protegem seus dados, mas resolvem problemas diferentes. Entenda a distinção antes de precisar restaurar.

Atualizado em 05 de agosto de 2026

Backup e snapshot são tratados como sinônimos com frequência. Não são. Os dois produzem uma cópia dos seus dados, mas nascem de necessidades diferentes: um protege você da próxima meia hora, o outro protege você do que você não viu chegando. Escolher errado só aparece no momento em que você tem menos paciência para descobrir isso.

A diferença em uma frase

O snapshot é uma foto do disco num instante exato, disparada por você, para desfazer algo que você está prestes a fazer. O backup é uma cópia agendada do servidor inteiro, disparada pelo sistema, para recuperar o que você não previu.

A distinção prática está em três eixos: quem dispara, quanto tempo a cópia vive, e do que ela te salva.

	Snapshot	Backup
Quem dispara	Você, manualmente	Agenda automática (diária)
Momento	Imediatamente antes de uma mudança	Sempre, sem você pensar nisso
Vida útil	Horas ou dias — você apaga quando o risco passou	Dias ou semanas, por retenção configurável
Custo	Proporcional ao que ocupa, enquanto existe	Proporcional ao volume guardado, enquanto a retenção durar
Cenário típico	Upgrade de kernel deu ruim	Alguém rodou `DELETE` sem `WHERE` na terça
Não serve para	Retenção longa e histórico	Rollback em cinco minutos

Quando o snapshot é a ferramenta certa

Use snapshot quando você está no controle da mudança e quer um caminho de volta curto:

apt full-upgrade ou troca de versão da distro
migração de versão major de PostgreSQL ou MySQL
mexer em kernel, módulos, /etc/fstab ou bootloader
primeira execução de um script de deploy que ainda não confia

No painel, você cria um snapshot do servidor antes de começar. A captura é instantânea e não exige derrubar a máquina, e você paga pelo espaço ocupado enquanto o snapshot existir. Isso muda o cálculo: um snapshot criado às 14h e removido às 15h é barato. Não existe motivo real para pular essa etapa — o passo a passo está em Snapshot antes de uma mudança arriscada.

Confira o disco antes, porque o tamanho do snapshot acompanha o que está gravado:

df -h /
lsblk

Se você acabou de acumular gigabytes de log, limpe primeiro. Não faz sentido pagar para fotografar lixo:

journalctl --vacuum-time=7d
du -sh /var/log/* | sort -h | tail

Quando o backup é a ferramenta certa

Backup cobre o que não passa pela sua cabeça no momento em que acontece: comando destrutivo em produção, ransomware, corrupção de filesystem, alguém removendo o servidor errado.

O snapshot que você deveria ter criado há três semanas não existe. É por isso que backup é agendado: ele não depende de disciplina humana. Retenção configurável significa que você tem várias datas para escolher, não apenas a última — o que importa quando o problema começou dias antes de você notar.

Regra prática: todo servidor do qual outra pessoa depende precisa de backup agendado. Snapshot é situacional e opcional. Backup não é. Quando chegar a hora de usar, o procedimento está em Como restaurar um backup.

O ponto cego dos dois

Snapshot e backup de disco são consistentes em nível de crash, não em nível de aplicação. Restaurar qualquer um dos dois é o equivalente a religar o servidor depois de uma queda de energia: o banco vai fazer crash recovery no boot, reaplicando o que estava no WAL e descartando transações não confirmadas.

Na maioria das vezes isso funciona. "Na maioria das vezes" não é a garantia que você quer para dados financeiros ou fiscais. Para isso, você precisa de um dump lógico, tirado pelo próprio banco, que sabe o que é uma transação:

pg_dump -Fc -U postgres appdb -f /var/backups/appdb-$(date +%F).dump

mysqldump --single-transaction --routines --triggers appdb \
  | gzip > /var/backups/appdb-$(date +%F).sql.gz

O --single-transaction existe por um motivo específico: em InnoDB ele obtém uma visão consistente sem travar as tabelas. Sem ele, o mysqldump bloqueia leitura e escrita durante o dump e sua aplicação para junto.

Um dump em /var/backups ainda mora no disco que pode falhar. Mande para fora da máquina:

aws s3 cp /var/backups/appdb-$(date +%F).dump \
  s3://meus-backups/postgres/ \
  --endpoint-url https://ENDPOINT-DO-SEU-BUCKET

Substitua o endpoint pelo do seu bucket. Se a AWS CLI ou o rclone ainda não estão configurados, comece por Configurar a AWS CLI e o rclone no seu bucket e depois automatize a rotina com Enviar backup de banco para um bucket.

Por que as três camadas coexistem

Snapshot: rollback de minutos, escopo de uma mudança.
Backup: servidor inteiro, escopo de dias.
Dump em bucket: o dado sobrevive mesmo que o servidor deixe de existir.

A terceira camada importa porque snapshot e backup estão amarrados ao servidor e à conta. Object Storage com região no Brasil dá a você uma cópia que não compartilha destino com a máquina de origem.

Dois números que você precisa saber

RPO é quanto dado você aceita perder. Backup diário às 3h significa até 24 horas de perda. RTO é quanto tempo você aceita ficar fora até voltar ao ar.

Escreva os dois números para cada serviço que você opera. Se não sabe respondê-los, você não tem política de backup — tem esperança.

Erros que aparecem sempre

Usar snapshot como arquivo de longo prazo. Ele custa enquanto existe e ocupa espaço proporcional ao disco. Guardar histórico não é o trabalho dele.

Nunca testar a restauração. Backup não verificado é hipótese, não proteção. Restaure num servidor descartável e confirme que a aplicação sobe. No mínimo, inspecione o dump:

pg_restore --list /var/backups/appdb-2026-08-04.dump | head

Esquecer o snapshot criado. Passada a mudança e validado o resultado, remova. Snapshot esquecido é fatura silenciosa.

Decisão rápida

Vai mexer em algo agora e quer voltar em dez minutos: snapshot. Quer poder voltar a ontem ou à semana passada: backup. Precisa do dado mesmo se este servidor desaparecer: dump para bucket. Se o caso não encaixa em nenhum dos três, vale falar com o suporte antes de improvisar.