ADR-042
Dump antes do deploy, e a falha dele aborta a publicação
O backup agendado roda por horário, então o mais recente pode ser de horas antes de uma migration corromper dado. A assimetria que sustenta a decisão: falhar com o banco no ar aborta a publicação, falhar com o banco parado não.
Contexto
A aplicação aplica as migrations no startup. Isso significa que uma publicação pode alterar o schema segundos depois de subir, e que uma migration que corrompa dado não tem como voltar ao estado de instantes antes. O backup agendado roda por horário, então o mais recente pode ser de horas atrás, e horas de dado de cliente é exatamente o que não se pode perder para consertar um erro de publicação.
Critérios que pesaram
Em ordem de peso.
- O ponto de restauração precisa ser imediatamente anterior à mudança, não da madrugada.
- Custo no passo mais caro do deploy: dumpar tudo dobraria o tempo.
- O arquivo não pode acumular no servidor indefinidamente.
- Servidor recém-provisionado não tem dado a perder, e não pode ser impedido de receber a primeira publicação.
Opções consideradas
- Confiar no backup agendado: zero custo no deploy, e deixa uma janela de horas entre a última cópia e a mudança de schema. Descartada.
- Dumpar os dois bancos, o da aplicação e o do Keycloak: cobertura total, e dobra o tempo do passo mais caro para proteger o banco que a publicação não altera. Descartada.
- Dump só do banco da aplicação, antes de qualquer alteração, com o mesmo formato dos backups agendados.
Decisão
O bloco de publicação grava um dump do PostgreSQL da aplicação antes de qualquer coisa mudar no servidor, antes inclusive de atualizar o código. Usa o mesmo formato comprimido de pg_dump dos backups agendados, então restaura pelo mesmo caminho, e o nome mantém o arquivo na mesma família do expurgo: ele aparece na tela de backups e vence pela retenção normal, em vez de acumular. O banco do Keycloak fica de fora, deliberadamente: o que a publicação muda são as migrations da aplicação. Se o dump falhar com o banco no ar, a publicação para antes de tocar em qualquer coisa: os containers atuais seguem servindo, e prosseguir seria entrar numa migration sem rede; os motivos plausíveis de falha, como disco cheio ou banco inacessível, são exatamente os que quebrariam a publicação adiante. Mas banco parado não aborta: servidor recém-provisionado não tem dado a perder, e abortar ali impediria a primeira publicação de subir, então o passo registra alerta e segue. E dump interrompido no meio é apagado: arquivo truncado é pior que arquivo nenhum.
Consequências
As duas metades pesam igual.
Melhorou
Existe um ponto de restauração de segundos antes de cada publicação, no mesmo formato e no mesmo lugar dos demais backups, sujeito à mesma retenção. É esse dump que a documentação de reversão referencia quando a migration é o problema.
Piorou
Cada publicação ficou mais lenta pelo tempo do dump, que cresce com o banco. E a proteção é parcial por desenho: o banco do Keycloak não é coberto por esse passo. Restaurar continua sendo operação manual, com ordem que importa (código primeiro, banco depois) e com um aviso que precisa estar escrito: restaurar joga fora tudo que foi gravado desde o início da publicação.
Revisitando hoje
Ainda de pé em set/2026. A parte mais útil é a assimetria: falhar com o banco no ar aborta, falhar com o banco parado não. É a diferença entre "não consegui proteger o que existe" e "não há o que proteger", e tratar as duas do mesmo jeito ou trava o primeiro deploy de um servidor novo, ou deixa passar uma publicação sem rede.
Segundo de três registros sobre backup. O anterior fez o backup existir de fato; este trata do ponto de restauração que continuava faltando, o de segundos antes de cada publicação.