Skip to main content
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 :
  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.