NoteBugsDocs

Funcionalidades

Backup e restauração

Um `.zip` com o banco e os arquivos, gerado por job e restaurado por partes.

Exportar é um job, não um download

Um .zip com o volume inteiro não cabe no tempo de uma requisição. Então a rota agenda a geração e devolve o estado; o arquivo é baixado depois, quando o status chega a READY.

StatusO que significa
IDLEnão há nada pedido
PENDING · RUNNINGa geração está na fila ou em curso
READYo .zip está no container, pronto para baixar
SENTo .zip foi para o bucket, e por isso o download local recusa
FAILEDalgo deu errado; o campo error diz o quê

Aqui ou no bucket

O .zip que fica no container tem nome fixo, uma cópia e prazo. O que vai para o bucket tem nome com hora, acumula e não expira: é o histórico, e é de lá que a restauração remota lê.

Backup automático

Diário, semanal ou por expressão cron, no fuso do container. O agendamento é gravado nas Configurações e viaja como um objeto inteiro: “semanal sem dia” e “cron sem expressão” não têm próxima ocorrência.

A próxima execução não é configuração

Ela é calculada pelo timer do processo, e se lê em /api/backup/schedule, não nas Configurações.

Restaurar: inspecionar antes

  1. 1Inspecionar lê o .zip e responde o que a restauração *faria*: um bloco por espaço, com a contagem de cada escopo. Não grava byte nenhum.
  2. 2Selecionar o que volta, por espaço de trabalho: só os cards, só os projetos, tudo.
  3. 3Importar aplica. Sem seleção, restaura tudo, menos as contas, que exigem pedido explícito.
  • O arquivo pode vir do disco (file) ou do bucket (remote), nunca os dois: isso é 400.
  • Origem remota não afrouxa validação nenhuma: dali para baixo só há bytes.
  • Escopo depende de escopo: epics exige projects, comments exige cards.