> ## Documentation Index
> Fetch the complete documentation index at: https://docs.casebender.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Ciclo di vita e migrazione MinIO

> Policy CaseBender per le distribuzioni legacy di MinIO Community Edition

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](/it/deployment/storage-migration-runbook):

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.