Skip to main content
MinIO Community Edition è entrato in distribuzione maintenance/source-only alla fine del 2025 e il suo repository community upstream è stato archiviato nel 2026. I server esistenti possono continuare a funzionare, ma i binari community upstream e la normale consegna delle patch non sono più un ciclo di vita di produzione affidabile. Questo stato upstream non crea un impegno di CaseBender a operare, patchare, ridistribuire o supportare MinIO. Consulta gli avvisi ufficiali attuali di MinIO e il contratto del tuo fornitore per i termini autorevoli del ciclo di vita di terze parti.

​
Policy CaseBender

  • Le nuove installazioni di produzione non possono selezionare un provider nativo minio.
  • I bundle e gli installer di produzione non incorporano un servizio MinIO, una credenziale root, un volume o un SDK MinIO nativo.
  • CaseBender non crea un nuovo bucket MinIO a runtime.
  • I valori enum storici del database e la cronologia delle migrazioni restano così gli upgrade non distruggono né reinterpretano i record esistenti.
  • Un servizio MinIO legacy può essere usato solo come sorgente di lettura durante una finestra di migrazione approvata.
  • Non viene fatta alcuna promessa di data di ritiro o di supporto a lungo termine oltre l’implementazione attuale. Le date specifiche del cliente appartengono a un piano di modifica approvato.
Non configurare un endpoint legacy come nuovo backend di produzione S3 generico senza certificazione live del prodotto esatto secondo la matrice della release attuale.

​
Finestra di migrazione

Definisci una finestra delimitata con:
  • owner e approvatore;
  • ultima immagine/versione sorgente supportata e revisione delle vulnerabilità;
  • tempi di write-freeze e di decisione di rollback;
  • scadenza della retention della sorgente;
  • set di recovery PostgreSQL più versione esatta dell’oggetto testato;
  • qualificazione live della destinazione;
  • target RPO/RTO ed evidenze di prova misurate; e
  • approvazione legal-hold/retention prima di qualsiasi smaltimento della sorgente.

​
Conserva prima di modificare qualsiasi cosa

Mantieni entrambi:
  1. uno snapshot/archivio a livello di storage del layout originale miniodata per il disaster recovery; e
  2. un export a livello di oggetto attraverso l’API S3 che preservi chiavi, metadata dove supportati, versioni degli oggetti, dimensioni e SHA-256 calcolati in modo indipendente.
Il layout interno del filesystem di MinIO non è un formato di import valido per un altro provider. Non copiare mai i file interni del volume direttamente nello object storage local o cloud. Esegui il backup di PostgreSQL allo stesso punto di consistenza e conserva .env, chiavi di crittografia, AUDIT_INTEGRITY_SECRET, digest delle immagini di release, trust TLS e credenziali della sorgente nei sistemi di secret/recovery approvati.

​
Migrazione copy-first

Usa Migrazione dello storage:
  1. inventory dei riferimenti oggetto PostgreSQL e delle versioni sorgente esatte;
  2. copia senza eliminare o sovrascrivere la sorgente;
  3. verifica la dimensione di destinazione e lo SHA-256 scaricato;
  4. registra ciascun elemento in StorageMigrationLedger;
  5. metti in quiescenza le write e copia il delta finale;
  6. passa alle read solo dopo la verifica;
  7. mantieni le read legacy/dual disponibili solo per la finestra di compatibilità documentata; e
  8. conserva la sorgente in sola lettura fino alla scadenza dell’approvazione di rollback.
Non usare sync, non eliminare la sorgente, non ruotare via le credenziali richieste né modificare le chiavi oggetto durante la copia iniziale.

​
Rollback

Il rollback richiede la sorgente originale e il punto di recovery del database corrispondente. Metti in quiescenza le write, copia le modifiche solo-destinazione indietro in modo non distruttivo, verifica SHA-256, quindi ripristina la configurazione del profilo precedente. Se la copia inversa non può essere dimostrata, ripristina l’insieme di consistenza completo PostgreSQL-più-oggetto. Non puntare mai un’applicazione più vecchia a uno schema di database che non supporta.

​
Validazione e chiusura

Esegui la qualificazione live della destinazione, i test applicativi upload/scan/promote/download/ delete, scripts/storage/verify-backup-restore.ts e una prova di rollback. Conserva evidenze sanitizzate, stato del ledger, conteggi, hash, RPO/RTO, approvazioni e autorizzazione allo smaltimento della sorgente.