Política do CaseBender
- Novas instalações de produção não podem selecionar um provedor nativo
minio. - Pacotes e instaladores de produção não incorporam um serviço MinIO, credencial root, volume ou SDK nativo do MinIO.
- O CaseBender não cria um novo bucket MinIO em tempo de execução.
- Valores históricos de enum no banco de dados e o histórico de migração permanecem para que upgrades não destruam nem reinterpretem registros existentes.
- Um serviço MinIO legado pode ser usado somente como origem de leitura durante uma janela de migração aprovada.
- Nenhuma data de desativação nem promessa de suporte de longo prazo é feita além da implementação atual. Datas específicas do cliente pertencem a um plano de mudança aprovado.
Janela de migração
Defina uma janela limitada com:- proprietário e aprovador;
- última imagem/versão de origem suportada e revisão de vulnerabilidades;
- tempos de freeze de escrita e de decisão de rollback;
- prazo de retenção da origem;
- conjunto testado de recuperação de PostgreSQL mais versão exata do objeto;
- qualificação live do destino;
- metas de RPO/RTO e evidência medida de ensaio; e
- aprovação de legal-hold/retenção antes de qualquer descarte da origem.
Preserve antes de alterar qualquer coisa
Mantenha ambos:- um snapshot/arquivo no nível de armazenamento do layout original
miniodatapara recuperação de desastres; e - uma exportação no nível de objeto pela API S3 preservando chaves, metadados quando suportados, versões de objeto, tamanhos e SHA-256 calculado de forma independente.
.env,
chaves de criptografia, AUDIT_INTEGRITY_SECRET, digests de imagem da release, confiança TLS e
credenciais de origem nos sistemas aprovados de segredos/recuperação.
Migração copy-first
Use Migração de armazenamento:- inventarie as referências de objeto no PostgreSQL e as versões exatas de origem;
- copie sem excluir nem sobrescrever a origem;
- verifique o tamanho no destino e o SHA-256 baixado;
- registre cada item em
StorageMigrationLedger; - silencie as escritas e copie o delta final;
- alterne as leituras somente após a verificação;
- mantenha leituras legadas/duplas disponíveis somente durante a janela de compatibilidade documentada; e
- retenha a origem somente leitura até o vencimento da aprovação de rollback.
sync, não exclua a origem, não rotacione as credenciais exigidas nem
altere chaves de objeto durante a cópia inicial.
Rollback
O rollback exige a origem original e o ponto de recuperação correspondente do banco de dados. Silencie as escritas, copie de volta as alterações exclusivas do destino de forma não destrutiva, verifique o SHA-256 e, em seguida, restaure a configuração anterior do perfil. Se a cópia reversa não puder ser comprovada, restaure o conjunto completo de consistência PostgreSQL-mais-objeto. Nunca aponte uma aplicação mais antiga para um schema de banco de dados que ela não suporte.Validação e encerramento
Execute a qualificação live do destino, testes de upload/scan/promote/download/ delete da aplicação,scripts/storage/verify-backup-restore.ts e um ensaio
de rollback. Retenha evidência sanitizada, status do ledger, contagens, hashes, RPO/RTO,
aprovações e autorização de descarte da origem.