ADR-0032 Backup e restauro do Postgres

Contexto

Operamos o Postgres nós próprios (ADR-0007), e esse ADR põe os backups e os testes de restauro na lista do que nos cabe. Não diz como.

• Os deployments variam: as nossas máquinas sob o Nodus (ADR-0016), a infraestrutura de um cliente ou um Postgres gerido. Cada um tem as suas ferramentas
• Os objetivos de recuperação são por produto: quantos dados se podem perder e quanto tempo pode demorar um restauro acordam-se com o responsável de cada produto, não para a empresa inteira
• A app não guarda estado durável próprio: ele vive no Postgres e no armazenamento de objetos (ADR-0030)

O que está em aberto: se uma ferramenta de backup é o padrão da empresa, e o que cada deployment deve em qualquer caso.

Opções consideradas

1. Uma ferramenta e um calendário da empresa em todo o lado

Prós: um só runbook; a prática de restauro passa de produto para produto. Contras: não serve um Postgres gerido nem a infraestrutura de um cliente; um só objetivo de recuperação é exigente demais para uns produtos e fraco demais para outros.

2. Backups feitos pela app (pg_dump a partir de um job agendado)

Prós: viaja com a imagem. Contras: a app teria credenciais de dump e chaves do armazenamento de backups; só dumps lógicos, sem recuperação point-in-time; a imagem precisaria de um pg_dump da versão do servidor.

3. Por deployment, com um registo obrigatório

Prós: cada ambiente usa a ferramenta que lhe serve, incluindo o que a plataforma já oferece. Contras: sem uniformidade — e o risco de ninguém o definir, a não ser que o registo seja obrigatório.

Decisão

O backup e o restauro definem-se por deployment. Não há uma ferramenta da empresa; há um mínimo da empresa.

Em concreto:

• Nunca é trabalho da app. Sem pg_dump na app nem no seu worker (ADR-0028), e sem credenciais de backup no ambiente da app
• Todos os deployments de produção registam, antes da entrada em produção: a ferramenta e o método (backups físicos com WAL para recuperação point-in-time, ou dumps lógicos), o calendário, a retenção, onde ficam as cópias (não na máquina da base de dados), como são cifradas, os objetivos de recuperação acordados (janela de perda de dados e tempo de restauro) e quem é alertado quando um backup falha
• Um backup só conta depois de testado um restauro a partir dele. Um teste de restauro antes da entrada em produção e, depois, no calendário que o deployment definir; o registo guarda a data do último
• O mesmo registo cobre os outros stores: o armazenamento de objetos (ADR-0030) e, onde os jobs em fila tenham de sobreviver à perda da máquina, o Valkey (ADR-0028)

Os fatores decisivos: os deployments são demasiado diferentes para uma só ferramenta, os objetivos de recuperação são uma decisão de produto e as credenciais de backup não pertencem a uma app. Aceitamos que dois produtos façam backups de formas diferentes.

Consequências

Mais fácil:

• Cada deployment usa o que a sua plataforma oferece em vez de contornar uma ferramenta imposta
• A imagem da app fica sem ferramentas de base de dados e sem segredos de backup

Mais difícil:

• Nada é uniforme: restaurar o produto A ensina pouco sobre o produto B
• O registo é a única salvaguarda — um deployment sem ele não tem um backup com que possamos contar
• Os testes de restauro levam tempo e têm de ser agendados, ou não acontecem

Do que abdicamos: de um só runbook para todas as bases de dados. Aceite — um backup que serve o seu deployment e já foi restaurado vale mais do que um padrão que não serve.