Cópias de segurança: a regra 3-2-1 e o restauro que ninguém testa
Toda a gente sabe que deve fazer cópias de segurança. O que se descobre tarde é que uma cópia por restaurar não é uma cópia — é uma esperança.
1. A regra 3-2-1
3 cópias dos dados — a original e duas.
2 suportes diferentes — não as duas no mesmo disco, nem as duas na mesma máquina.
1 fora do sítio — noutro edifício, ou noutro fornecedor.
O "fora do sítio" não é paranoia de incêndios: é a resposta ao ransomware, que cifra tudo o que a máquina consegue alcançar — incluindo o disco das cópias, se ele estiver montado.
2. Uma cópia de Postgres, em duas linhas
# Uma base
pg_dump -Fc -U utilizador base > base-$(date +%F).dump
# Todas, num servidor com várias
pg_dumpall -U postgres > tudo-$(date +%F).sqlO -Fc é o formato próprio do Postgres: comprimido, e permite restaurar só uma tabela com o pg_restore. Com várias bases no mesmo servidor, o pg_dumpall apanha também os utilizadores e as permissões — que é a parte que falta quando se restaura só a base e nada funciona.
3. A parte que se salta
# Restaurar para uma base descartável, e ver se lá está tudo
createdb ensaio
pg_restore -d ensaio base-2026-06-25.dump
psql -d ensaio -c "SELECT count(*) FROM artigos;"Marque isto no calendário — de três em três meses chega. Os modos de falhar são sempre os mesmos: o ficheiro tem zero bytes há semanas, o disco encheu, a password mudou e o script falha em silêncio, ou o dump está bom mas ninguém sabe o comando para o repor.
4. Duas perguntas antes de desenhar o resto
Quanto tempo posso perder? Se a resposta for "um dia", uma cópia diária chega. Se for "uma hora", a cópia diária não serve e é preciso arquivar o registo de transações.
Quanto tempo demora a repor? Uma cópia de 200 GB que demora seis horas a restaurar é uma decisão que se toma antes do desastre, e não durante.
E a rotação: sem apagar as antigas, o disco enche e as cópias param — normalmente sem ninguém reparar, até ao dia em que fazem falta.
# Guardar sete dias
find /backups -name '*.dump' -mtime +7 -delete