> ## 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.

# Cycle de vie et migration MinIO

> Politique CaseBender pour les déploiements MinIO Community Edition hérités

MinIO Community Edition est passé en distribution maintenance/source
uniquement fin 2025 et son dépôt communautaire amont a été archivé en 2026.
Les serveurs existants peuvent continuer à fonctionner, mais les binaires
communautaires amont et la livraison normale de correctifs ne constituent
plus un cycle de vie de production fiable.

Ce statut amont ne crée aucun engagement CaseBender à exploiter, corriger,
redistribuer ou supporter MinIO. Consultez les avis officiels actuels de
MinIO et votre contrat fournisseur pour les termes de cycle de vie
tiers faisant autorité.

## Politique CaseBender

* Les nouvelles installations de production ne peuvent pas sélectionner un
  fournisseur natif `minio`.
* Les lots et installeurs de production n'intègrent pas de service MinIO,
  d'identifiant root, de volume ni de SDK MinIO natif.
* CaseBender ne crée pas de nouveau bucket MinIO à l'exécution.
* Les valeurs d'énumération historiques de la base de données et l'historique
  de migration sont conservés afin que les mises à niveau ne détruisent ni ne
  réinterprètent les enregistrements existants.
* Un service MinIO héritage ne peut être utilisé que comme source de lecture
  pendant une fenêtre de migration approuvée.
* Aucune date de retrait ni promesse de support à long terme n'est faite
  au-delà de l'implémentation actuelle. Les dates spécifiques au client
  appartiennent à un plan de changement approuvé.

Ne configurez pas un point de terminaison héritage comme nouveau backend S3
générique de production sans certification en direct du produit exact sous la
matrice de version actuelle.

## Fenêtre de migration

Définissez une fenêtre bornée avec :

* un propriétaire et un approbateur ;
* la dernière image/version source supportée et une revue de vulnérabilités ;
* les horaires de gel des écritures et de décision de rollback ;
* la date limite de rétention de la source ;
* un ensemble de reprise PostgreSQL plus versions exactes d'objets testé ;
* la qualification en direct de la destination ;
* les cibles RPO/RTO et les preuves de répétition mesurées ; et
* l'approbation de conservation légale/rétention avant toute élimination de
  la source.

## Préserver avant de modifier quoi que ce soit

Conservez les deux :

1. un instantané/archive au niveau stockage de la disposition `miniodata`
   d'origine pour la reprise après sinistre ; et
2. un export au niveau objet via l'API S3 préservant les clés, les
   métadonnées lorsque c'est supporté, les versions d'objets, les tailles et
   un SHA-256 calculé indépendamment.

La disposition interne du système de fichiers MinIO n'est pas un format
d'import valide pour un autre fournisseur. Ne copiez jamais les fichiers de
volume internes directement dans un stockage objet local ou cloud.

Sauvegardez PostgreSQL au même point de cohérence et conservez `.env`, les
clés de chiffrement, `AUDIT_INTEGRITY_SECRET`, les digests d'image de
version, la confiance TLS et les identifiants source dans les systèmes de
secrets/reprise approuvés.

## Migration copy-first

Utilisez [Migration du stockage](/fr/deployment/storage-migration-runbook) :

1. inventorier les références d'objets PostgreSQL et les versions source
   exactes ;
2. copier sans supprimer ni écraser la source ;
3. vérifier la taille de destination et le SHA-256 téléchargé ;
4. enregistrer chaque élément dans `StorageMigrationLedger` ;
5. mettre les écritures au repos et copier le delta final ;
6. basculer les lectures uniquement après vérification ;
7. conserver les lectures héritage/duales disponibles uniquement pendant la
   fenêtre de compatibilité documentée ; et
8. conserver la source en lecture seule jusqu'à expiration de l'approbation
   de rollback.

N'utilisez pas `sync`, ne supprimez pas la source, ne faites pas tourner les
identifiants requis et ne changez pas les clés d'objets pendant la copie
initiale.

## Rollback

Le rollback exige la source d'origine et le point de reprise de base de
données correspondant. Mettez les écritures au repos, copiez les
changements uniquement destination vers la source de façon non destructive,
vérifiez le SHA-256, puis restaurez la configuration de profil précédente.
Si la copie inverse ne peut pas être prouvée, restaurez l'ensemble de
cohérence PostgreSQL-plus-objets complet.

Ne pointez jamais une application plus ancienne vers un schéma de base de
données qu'elle ne supporte pas.

## Validation et clôture

Exécutez la qualification en direct de la destination, les tests
applicatifs téléversement/analyse/promotion/téléchargement/suppression,
`scripts/storage/verify-backup-restore.ts` et une répétition de rollback.
Conservez les preuves assainies, le statut du registre, les comptages, les
hachages, le RPO/RTO, les approbations et l'autorisation d'élimination de
la source.