## Introduction

Ce guide montre comment sauvegarder et restaurer MinIO avec des commandes que vous pouvez exécuter dès aujourd’hui. Vous découvrirez un flux de production simple, comment valider les résultats, comment planifier les retours arrière et les erreurs à éviter. Les exemples utilisent le client MinIO (mc) afin que vous puissiez tester localement avant de déployer sur serveurs, Docker ou Kubernetes.

Ce que vous obtiendrez :

- Des motifs de sauvegarde et restauration clairs, automatisables.

- Des commandes concrètes pour snapshots, miroirs continus et validation.

- Un pilote local étroit que vous pouvez terminer en moins d’une heure.

## Vue d’ensemble du workflow

Un flux fiable de sauvegarde et restauration MinIO :

- Inventorier ce qu’il faut protéger

- Données d’objets : tous les buckets pertinents.

- Historique des versions : permet la récupération à un instant donné.

- Identifiants et politiques : utilisateurs, groupes, règles d’accès.

- Clés de chiffrement et paramètres si vous utilisez SSE‑KMS (Server‑Side Encryption with KMS – chiffrement côté serveur avec KMS, un service de gestion de clés).

- Choisir un motif de sauvegarde

- Snapshots périodiques vers des préfixes immuables datés.

- Miroir continu pour un standby chaud.

- Hybride : les deux, pour couvrir la récupération à un instant donné et un RPO (Recovery Point Objective – objectif de point de récupération) proche de zéro.

- Activer des garde-fous

- Versioning des buckets sur les données critiques.

- Rétention d’objets optionnelle pour éviter les suppressions accidentelles.

- Automatiser et planifier

- Exécuter les sauvegardes à intervalles réguliers ou en continu pour les miroirs.

- Journaliser les résultats et alerter en cas d’échec.

- Valider

- Comparer compteurs, tailles et différences.

- Vérifier ponctuellement les métadonnées d’objets.

- Documenter la restauration et le rollback

- Commandes exactes et ordre d’exécution.

- Prérequis : clés, utilisateurs, politiques.

- Checklist courte de répétition de restauration.

## Prérequis et hypothèses

- Client MinIO (mc) installé et accès réseau à vos endpoints MinIO.

- Capacité suffisante sur la destination de sauvegarde (autre MinIO, stockage compatible S3 ou passerelle d’objets sur site).

- Si vous utilisez le chiffrement côté serveur avec un KMS (Key Management Service – service de gestion de clés), sauvegardez les clés et la configuration. La perte des clés rend les données chiffrées irrécupérables.

- Utiliser des identifiants de test non root pour les pilotes et le principe du moindre privilège en production.

## Motifs de sauvegarde pratiques

### Motif A : snapshots périodiques (préfixes datés)

Utilisez un préfixe de snapshot daté pour la récupération à un instant donné.

# Alias (adaptez endpoints et identifiants)
mc alias set primary http://localhost:9000 minio minio123
mc alias set backup http://localhost:9002 minio minio123

# Activer le versioning sur les buckets critiques (optionnel mais recommandé)
mc version enable primary/data

# Snapshot vers un préfixe daté
DATE=$(date -u +%Y%m%dT%H%M%SZ)
mc mirror --overwrite primary/data backup/snapshots/$DATE 
 Les restaurations ultérieures peuvent cibler backup/snapshots/20260101T000000Z .

Notes :

- Les snapshots ne suppriment pas les sauvegardes plus anciennes. Utilisez des règles de cycle de vie côté backup pour expirer les vieux snapshots si nécessaire.

- Gardez les snapshots en lecture seule pour plus de sécurité dans la mesure du possible.

### Motif B : miroir continu (standby chaud)

Maintenez une copie quasi temps réel sur un endpoint secondaire.

# Synchronisation complète unique
mc mirror --overwrite primary/data backup/data

# Mises à jour continues (exécution en premier plan ; envisagez un gestionnaire de processus pour la production)
mc mirror --watch --overwrite primary/data backup/data 
 Attention :

- Ajoutez --remove seulement si vous souhaitez que les suppressions sur le primaire se propagent au backup. Comprenez le risque avant de l’activer.

### Garde-fous qui améliorent la récupération

# Activer le versioning
mc version enable primary/data

# Optionnel : rétention gouvernance 30 jours sur tous les objets
# Ajustez selon conformité et charges de travail
mc retention set governance 30d primary/data 

### Sauvegardes de configuration et d’identité

 Conservez tout ce qui est nécessaire pour reconstruire un endpoint :

- Fichiers d’environnement ou manifests définissant les identifiants root et les options du serveur.

- Utilisateurs, groupes et politiques. Notez comment les recréer ; par exemple :

mc admin user list primary
 mc admin policy list primary 

- Si vous utilisez un KMS, gardez les clés et les paramètres de connexion en lieu sûr et récupérable.

## Restauration et reprise après sinistre

### Restauration à froid depuis un snapshot daté

 Lorsque le primaire est sain mais que les données doivent être remises à un état antérieur :

# Choisir un point dans le temps du snapshot et le remirrorer
SNAP=20260101T000000Z
mc mirror --overwrite backup/snapshots/$SNAP primary/data 

### Basculement chaud via le miroir

 Si le primaire est hors service, pointez les applications vers backup/data . Après reconstruction du primaire, remirrorer pour le repeupler :

# Après reconstruction du primaire avec une configuration identique ou compatible
mc mirror --overwrite backup/data primary/data 

### Restauration de la configuration

- Recréez utilisateurs et politiques tels qu’enregistrés. Validez l’accès avec une lecture et une écriture d’objet test.

- Restaurez les clés KMS et les paramètres avant de lire des objets chiffrés.

## Contrôles de validation

 Exécutez ces vérifications après chaque job de sauvegarde et avant de déclarer une restauration terminée.

# Compter les objets (écrire dans un fichier puis compter)
mc ls --recursive primary/data > primary_list.txt
wc -l primary_list.txt
mc ls --recursive backup/data > backup_list.txt
wc -l backup_list.txt

# Comparer la taille totale
mc du primary/data
mc du backup/data

# Trouver les différences
mc diff --recursive primary/data backup/data

# Vérifier ponctuellement quelques objets
mc stat primary/data/path/to/object
mc stat backup/data/path/to/object 
 Conseils :

- Automatisez au minimum les compteurs, la taille et le diff. Alertez sur les écarts.

- L’ETag n’équivaut pas toujours au MD5 pour les uploads multipart ; utilisez diff et taille pour une confiance accrue.

## Planification du rollback

### Avec des buckets versionnés

Lister les versions et restaurer une version précise :

# Inspecter les versions
mc ls --versions primary/data/path/to/object

# Restaurer une version choisie par-dessus l’actuelle
mc cp --version-id <VERSION_ID> \
 primary/data/path/to/object \
 primary/data/path/to/object 

### Avec des snapshots de sauvegarde

 Remonter un bucket en miroirant un snapshot connu bon :

SNAP=20260101T000000Z
mc mirror --overwrite backup/snapshots/$SNAP primary/data 
 Effectuez toujours un dry‑run sur un bucket de test d’abord, puis réalisez le rollback en production pendant une fenêtre de maintenance le cas échéant.

## Plan de pilote local

Un petit pilote mesurable prouve le flux et révèle les besoins d’ajustement.

- Démarrer deux conteneurs MinIO locaux

# Primaire sur 9000
 docker run -d --name minio1 -p 9000:9000 \
 -e MINIO_ROOT_USER=minio -e MINIO_ROOT_PASSWORD=minio123 \
 quay.io/minio/minio server /data

 # Backup sur 9002
 docker run -d --name minio2 -p 9002:9000 \
 -e MINIO_ROOT_USER=minio -e MINIO_ROOT_PASSWORD=minio123 \
 quay.io/minio/minio server /data 

- Configurer mc et créer des données de test

 mc alias set primary http://localhost:9000 minio minio123
 mc alias set backup http://localhost:9002 minio minio123

 mc mb primary/data
 # Créer quelques objets de test sans pipeline
 for i in $(seq 1 100); do
 echo "file $i" > /tmp/obj-$i.txt
 mc cp /tmp/obj-$i.txt primary/data/obj-$i.txt
 done 

- Exécuter une sauvegarde unique et valider

 mc mirror --overwrite primary/data backup/data
 mc du primary/data && mc du backup/data
 mc diff --recursive primary/data backup/data 

- Simuler une perte et restaurer

 # Simuler suppression sur le primaire
 mc rm --recursive --force --older-than 0s primary/data/obj-1.txt

 # Restaurer depuis le backup
 mc mirror --overwrite backup/data primary/data

 # Valider
 mc diff --recursive primary/data backup/data 

- Essayer un snapshot daté

 DATE=$(date -u +%Y%m%dT%H%M%SZ)
 mc mirror --overwrite primary/data backup/snapshots/$DATE 
 Critères de réussite :

- Les compteurs et tailles d’objets correspondent après sauvegarde et après restauration.

- mc diff n’affiche aucune différence.

- Commandes et durées sont enregistrées pour l’automatisation future.

## Erreurs fréquentes

- Ne pas activer le versioning avant des modifications critiques.

- Utiliser --remove sur le miroir sans comprendre qu’il propage les suppressions.

- Oublier de sauvegarder identifiants, politiques et clés de chiffrement.

- Ne pas tester les restaurations avant qu’un incident ne survienne.

- Supposer que l’ETag équivaut toujours au MD5 (peut différer pour les uploads multipart).

- Omettre la validation et la journalisation de chaque exécution.

## Conclusion

Commencez par un pilote local étroit, puis étendez le même motif en production. Maintenez le versioning activé, protégez clés et configurations, et validez chaque sauvegarde et chaque restauration. Documentez les commandes exactes de restauration et répétez‑les pour atteindre vos objectifs de reprise avec confiance.