Como são feitas as cópias de segurança por dentro
Publicado em 2026-09-12 por frfrand
Qué es un backup en caliente, por qué un volcado y una copia física resuelven problemas distintos, cómo funciona la deduplicación y para qué sirve verificar con hash.
"Fazer backup" soa como uma única operação e, na verdade, são várias decisões encadeadas. Vale conhecê-las porque explicam por que às vezes uma cópia serve e outra não.
Dump lógico e cópia física
O dump lógico (pg_dump, mysqldump) gera as instruções necessárias para reconstruir os dados: criar tabelas, inserir linhas. É texto, ou um formato próprio comprimido.
Vantagens: é portável entre versões do mecanismo e até entre sistemas operativos, pode ser restaurado parcialmente (uma única tabela) e pode ser inspecionado.
Desvantagem: é lento em bases grandes, tanto ao gerá-lo quanto ao restaurá-lo, porque restaurar significa voltar a executar todas essas inserções e reconstruir todos os índices.
A cópia física copia os ficheiros de dados tal como estão. Muito mais rápida em bases grandes e é a base da recuperação a um ponto no tempo.
Desvantagem: está atada à versão do mecanismo e à arquitetura. Não podes restaurar uma cópia física do Postgres 15 num Postgres 17.
A estratégia habitual usa as duas: física para a recuperação rápida, lógica periódica como rede de segurança portátil.
O que significa "em quente"
Uma cópia em quente é feita sem parar a base de dados. O desafio é óbvio: enquanto copias ficheiros, a base continua a escrever. Algumas páginas são copiadas no meio de uma modificação.
O truque não é pausar, é marcar:
- A base anota a posição exata em seu registro de gravações (o WAL no Postgres).
- Os arquivos são copiados, com tráfego normal ocorrendo.
- O registro de gravações também é copiado a partir dessa marca.
Ao restaurar, o motor reproduz esse registro sobre os arquivos e repara qualquer página que tenha ficada pela metade. O resultado é consistente.
Por isso uma cópia ingênua dos arquivos de uma base em funcionamento pode ser inútil: falta a segunda metade.
E é também o que permite a recuperação a um ponto no tempo: se você guardar o registro contínuo, pode restaurar a cópia e reproduzir até as 14:37, justo antes da exclusão acidental.
Incrementais e deduplicação
Uma cópia incremental guarda apenas o que mudou. A pergunta interessante é como se sabe o que mudou.
As ferramentas modernas dividem os arquivos em blocos e calculam o hash de cada bloco. Se o hash já existir no repositório, não é salvo novamente: é salva uma referência.
Isso gera um efeito muito útil: você pode ter trinta cópias diárias de um banco de 100 GB ocupando muito menos que 3 TB, porque a maioria dos blocos se repete. E cada cópia se comporta como uma completa ao restaurar, embora fisicamente seja incremental.
Por que o hash importa
Salvar o hash de cada cópia serve para detectar corrupção silenciosa.
Os discos falham de formas sutis: um bit que muda sem que ninguém avise. Se isso acontece em um backup, você descobre no dia em que precisar dele.
Com o hash salvo ao lado, é possível verificar periodicamente sem restaurar nada. É barato e responde a uma pergunta importante: esse arquivo ainda é o que eu salvei?
Isso dito: o hash confirma que o arquivo está íntegro, não que seja útil. Para isso, é preciso restaurá-lo.
Criptografia e localização
Duas coisas que são esquecidas com frequência:
- Criptografar antes de sair. Um despejo não tem dentro nenhum dos permissões do banco. É texto com todos os seus dados.
- Salvar em outra máquina. Idealmente com outro provedor, e com credenciais distintas das de produção. Se quem compromete seu servidor também puder apagar seus backups, você não tem backups.
Na ArduMaker, cada VPS tem uma cópia completa periódica em caliente, em um host distinto daquele que executa o VPS, verificada com seu hash e com instruções de restauração ao lado.
