Um backup que nunca restaurou não é um backup

O pior momento para descobrir que um backup não funciona é precisamente quando precisa dele. E, ainda assim, o padrão esmagadoramente comum é exatamente esse: backups configurados uma vez, um visto verde num dashboard durante dezoito meses e, depois, uma restauração que produz uma base de dados vazia.

Testar a restauração de um backup de base de dados não é uma best practice opcional, como acontece com a maioria das best practices. Um backup é uma afirmação e, até restaurar um, essa afirmação não foi testada.

Eis como falham e o que uma verificação tem realmente de validar.

As quatro formas de um backup ser silenciosamente inútil

1. Está vazio e ninguém verificou

Um pg_dump que falha a meio ainda pode produzir um ficheiro. Um dump executado com o nome de base de dados errado produz um ficheiro válido, correto e vazio. Ambos parecem bem-sucedidos para qualquer sistema que verifique apenas um código de saída diferente de zero ou a existência do ficheiro.

A verificação mais barata do mundo: veja o tamanho e compare-o com o de ontem. Um backup com 400 bytes quando o de ontem tinha 40 MB já lhe disse tudo. Um backup que tem 400 bytes há seis meses tem estado a avisá-lo durante todo esse tempo.

2. Contém dados, mas não contém o que os rodeia

Um pg_dump de uma única base de dados não inclui roles nem outras bases de dados. Restaure-o num servidor novo e as tabelas aparecem, mas todos os GRANT fazem referência a uma role que não existe. A sua app liga-se e recebe permission denied em tudo.

As extensões seguem a mesma lógica. Se o seu schema depender de pgcrypto ou uuid-ossp e o destino não as tiver, a restauração falha a meio, deixando algumas tabelas para trás.

3. As flags estavam erradas para a restauração de que precisa

pg_dump produz resultados diferentes consoante o formato, e o erro costuma ser descoberto sob pressão:

• Plain SQL é restaurado com psql e é legível por humanos. Não pode ser restaurado seletivamente e é lento para bases de dados grandes.
• Custom format (-Fc) é restaurado com pg_restore, suporta paralelismo e restauração seletiva e é o formato certo para qualquer base de dados de dimensão significativa.

Fazer o backup em plain format porque o tutorial o fez e descobrir durante um incidente que não consegue restaurar uma única tabela é uma forma particularmente específica e evitável de ter um dia mau.

4. Não consegue desencriptá-lo

Se os backups forem encriptados — e devem ser —, a chave faz parte do backup. Uma chave que exista apenas na máquina que foi perdida ou apenas numa variável de ambiente do serviço que está indisponível é uma chave que não terá quando for necessária.

Como é uma verificação real

O teste não é "o ficheiro existe?". É restaurá-lo noutro local e fazer-lhe uma pergunta.

# 1. Restore into a scratch database, not the live one
createdb verify_$(date +%Y%m%d)
pg_restore -d verify_$(date +%Y%m%d) --no-owner --no-privileges latest.dump

# 2. Ask it something only real data can answer
psql -d verify_$(date +%Y%m%d) -c "
  select
    (select count(*) from users)            as users,
    (select count(*) from orders)           as orders,
    (select max(created_at) from orders)    as newest_order;
"

# 3. Drop it
dropdb verify_$(date +%Y%m%d)

O passo 2 é o objetivo de tudo isto. Uma restauração que termina sem erros ainda não lhe diz nada sobre a presença dos dados. As contagens de linhas e uma verificação de recência dizem.

Vale a pena validar três coisas:

• As contagens de linhas estão na ordem de grandeza certa. Não têm de ser exatas — os dados mudam —, mas uma tabela que tinha 200 000 linhas e agora tem 12 representa uma falha.
• O registo mais recente é recente. Se a encomenda mais recente no seu backup "noturno" for de março, o seu job de backup parou em março.
• A app consegue realmente ligar-se. Aponte uma instância de staging para a base de dados restaurada e carregue uma página.

Faça-o com uma periodicidade definida, não quando se lembrar

A periodicidade realista é mensal e automatizada, com o resultado num local onde o irá notar. Um lembrete no calendário para "testar backups" é um lembrete que vai adiar.

O que faz com que isto funcione é tornar a falha impossível de ignorar: se a query de verificação devolver menos linhas do que um determinado limite, isso deve gerar um alerta para alguém, tal como aconteceria com um erro de produção. Um sistema de backup que falha silenciosamente é indistinguível de não ter sistema de backup, até ao momento em que faz falta.

Como o Dockup trata esta questão

Três decisões, cada uma direcionada para uma falha específica acima.

Os backups vão para outro local. Um backup no mesmo disco que a base de dados não é um backup — é uma cópia que desaparece com o disco. O Dockup transmite os backups de bases de dados diretamente para object storage à medida que são produzidos, para que o ficheiro nunca dependa do host que o criou.

São encriptados e a chave não fica na máquina. Os backups são encriptados com AES-256-GCM durante a transmissão. O que importa para a recuperação é que a chave é mantida pela plataforma, em vez de ficar no ambiente do serviço que está a ser salvaguardado.

Um backup que não produziu nada não é registado como backup. Esta é a medida que trata diretamente da falha de ficheiros vazios: se o dump terminar com um código diferente de zero ou produzir zero bytes, o upload é eliminado e o backup é registado como falhado. Não acaba com uma lista de entradas verdes em que uma delas é um ficheiro de 400 bytes.

dockup db backup my-project/main-db --json     # take one now
dockup db backups my-project/main-db --json    # list them with sizes

Os tamanhos apresentados nessa lista são a verificação de integridade mais barata que tem. Acompanhe a sua evolução.

A pergunta incómoda

Se a sua base de dados de produção fosse destruída nos próximos dez minutos, quanto tempo demoraria a tê-la de volta e quanto teria perdido?

Se não consegue responder aos dois números, não tem uma estratégia de backup — tem ficheiros de backup. A diferença está inteiramente em saber se alguém alguma vez fez a restauração.

Perguntas frequentes

Com que frequência devo testar uma restauração? Mensalmente é uma periodicidade razoável por predefinição, de forma automatizada e não manual. O importante é que uma falha seja impossível de ignorar, não que a periodicidade seja agressiva.

Porque é que a minha restauração terminou, mas não produziu dados? Normalmente, o dump foi feito na base de dados errada ou falhou a meio enquanto continuava a escrever um ficheiro. Compare os tamanhos dos backups ao longo do tempo — um dump vazio é evidente numa tendência de tamanhos e invisível numa coluna de estado.

Os backups devem ser encriptados? Sim, e a chave deve ficar num local que sobreviva à perda da máquina. Um backup encriptado cuja chave estava no servidor perdido não pode ser recuperado.

Um snapshot é o mesmo que um backup? Não. Um snapshot de volume captura o disco, incluindo o estado em que a base de dados se encontrava naquele instante. Um dump lógico é consistente por construção. A maioria das equipas quer ambos, para falhas diferentes.