Skip to main content
O MinIO Community Edition entrou em distribuição de manutenção/somente código-fonte no final de 2025 e seu repositório comunitário upstream foi arquivado em 2026. Servidores existentes podem continuar em execução, mas os binários comunitários upstream e a entrega normal de patches deixaram de ser um ciclo de vida de produção confiável. Esse status upstream não cria um compromisso do CaseBender de operar, aplicar patches, redistribuir ou dar suporte ao MinIO. Consulte os avisos oficiais atuais do MinIO e o contrato com seu fornecedor para os termos autoritativos de ciclo de vida de terceiros.

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.
Não configure um endpoint legado como um novo backend S3 genérico de produção sem certificação live do produto exato sob a matriz da release atual.

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:
  1. um snapshot/arquivo no nível de armazenamento do layout original miniodata para recuperação de desastres; e
  2. 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.
O layout interno do sistema de arquivos do MinIO não é um formato de importação válido para outro provedor. Nunca copie arquivos internos de volume diretamente para armazenamento de objetos local ou em nuvem. Faça backup do PostgreSQL no mesmo ponto de consistência e preserve .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:
  1. inventarie as referências de objeto no PostgreSQL e as versões exatas de origem;
  2. copie sem excluir nem sobrescrever a origem;
  3. verifique o tamanho no destino e o SHA-256 baixado;
  4. registre cada item em StorageMigrationLedger;
  5. silencie as escritas e copie o delta final;
  6. alterne as leituras somente após a verificação;
  7. mantenha leituras legadas/duplas disponíveis somente durante a janela de compatibilidade documentada; e
  8. retenha a origem somente leitura até o vencimento da aprovação de rollback.
Não use 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.