Sauvegardes « 3-2-1 » dans un cluster MinIO / S3-compatible

Introduction

Guide pratique pour bâtir une stratégie de protection des données souveraine, immuable et multi-site.

Pourquoi encore parler de sauvegarde ?

En 2025, les attaques ransomware et les erreurs humaines restent la première cause de perte de données, et les instances objets ne sont plus épargnées. Même les environnements cloud-natifs doivent donc appliquer une règle simple : « les sauvegardes qui ne sont pas testées, hors-ligne et hors-site n’existent pas ». La bonne vieille stratégie 3-2-1 (3 copies, 2 supports, 1 copie hors-site) garde toute sa pertinence… à condition d’être adaptée aux architectures objet modernes et aux impératifs réglementaires (immuabilité, traçabilité).

3-2-1 (et variantes 3-2-1-1-0)

Règle	Signification	Objectif
3	3 copies des données (dont la prod)	Tolérance aux corruptions/locales
2	Stockées sur 2 supports différents	Résilience matérielle/logique
1	Au moins 1 copie hors-site	Sinistre total, région indisponible
+ 1	1 copie immuable (object-lock)	Protection ransomware
+ 0	0 erreur : tests de restauration réguliers	Restaurabilité garantie

Le modèle 3-2-1-1-0 ajoute une couche immuable et l’obligation de tester les backups : MinIO simplifie ces deux exigences grâce à Object Lock et à la réplication multi-site.

Pourquoi choisir MinIO comme “backend” objet ?

1. Compatibilité complète S3

Intégration native avec les outils de backup (Restic, Velero, Veeam, Borg, etc.).

2. Performance & scalabilité

Erasure coding distribué, +1 To/s agrégé sur 32 nœuds dans les benches publics.

3. Immutabilité certifiée

Object Lock (mode Compliance ou Governance) validé par Cohasset Associates pour SEC 17a-4, FINRA 4511…, ce qui répond aux exigences RGPD et DORA sur la conservation inviolable.

4. Réplication Active-Active multi-site

Synchro bidirectionnelle ou « mesh » pour distribuer automatiquement la copie hors-site.

5. 100 % open-source

Déployable on-prem, cloud, edge, assorti d’un support commercial si besoin.

Étude de cas : un SaaS FinTech qui protège 500 To de données client

Contexte	Solution mise en place	Résultat mesuré (3 mois)
Startup FinTech (Paris) – 60 micro-services, base PostgreSQL 15, 500 To d’objets (reçus PDF, export CSV). Exigences : conformité DORA/BALE III, RPO ≤ 15 min, RTO ≤ 2 h, budget < 0,02 €/Go/mois.	– 2 clusters MinIO de 12 nœuds / site (DC Paris + DC Lyon) – Erasure coding 8+4, réseau 25 GbE – Object Lock Compliance 180 j – Réplication active-active vers le deuxième site – Backups orchestrés par Restic via GitLab CI	– RPO réel : 7 min (tests mensuels) – RTO moyen : 41 min pour restaurer une base de 3 To – Coût total : 0,013 €/Go/mois (CAPEX amorti 3 ans + énergie) → 38 % moins cher qu’une tierce offre cloud – Audit DORA validé sans non-conformité (grâce à l’immutabilité + journal S3)

Leçon clef : la combinaison erasure coding + object-lock permet de respecter à la fois les cibles de continuité d’activité et les exigences réglementaires, tout en restant compétitif face à l’hyperscaler.

Automatisation GitOps : Terraform + GitLab CI pour des sauvegardes testées en continu

1. Répertoire mono-repo

infra/
  terraform/
    main.tf          # crée/synchronise les clusters MinIO
    outputs.tf
backup/
  restic/
    restic.sh        # script wrapper backup/restore
.gitlab-ci.yml

2. Pipeline GitLab CI (extrait)

stages:
  - deploy
  - backup
  - restore-test

deploy_minio:
  stage: deploy
  script:
    - cd infra/terraform
    - terraform init
    - terraform apply -auto-approve

daily_backup:
  stage: backup
  script:
    - ./backup/restic/restic.sh backup /data
  rules:
    - schedule: "0 2 * * *"   # 02:00 CEST tous les jours

weekly_restore_test:
  stage: restore-test
  script:
    - ./backup/restic/restic.sh restore --verify
  rules:
    - schedule: "0 5 * * 1"   # 05:00 CEST chaque lundi

3. Points forts du workflow

a. Infrastructure as Code

terraform plan tourné à chaque merge request → visibilité des diffs IAM, versioning, Object Lock.

b. Sauvegardes déclaratives

La stratégie (fréquence, tags de rétention) vit dans restic.sh → traçable en Git.

c. Tests de restauration continus

Le job weekly_restore_test monte un conteneur éphémère, récupère la dernière snapshot et vérifie le hash SHA-256.
Si le test échoue, une alerte est poussée dans Slack + crée un incident GitLab.

d. Observabilité intégrée

Chaque job publie dans Prometheus : durée, volume copié, intégrité vérifiée.
Alertmanager déclenche si la durée > 150 % de la médiane ou si l’intégrité échoue deux fois d’affilée.

Avec cette approche GitOps :

Zéro drift : l’état réel = l’état décrit dans Git.
Audit simplifié : tous les changements d’infra et de politique de backup sont historisés par commit.
Fiabilité mesurable : le succès du test de restauration devient un Service Level Indicator (SLI) partagé à la direction.

Bonnes pratiques complémentaires

Thème	Conseils
Chiffrement transit & repos	TLS par défaut, SSE-S3 ou SSE-C pour les backups sensibles.
Segmentation IAM	Un compte backup-writer sans droit de suppression + un compte restore-reader.
Lifecycle	Purgez automatiquement les versions > 90 jours pour limiter la facture disque.
Monitoring	Exporter les métriques Prometheus (`minio_cluster_*`), Alertmanager sur `bucket_usage_free_bytes`.
Ransomware drills	Simulez un compte compromis : vérifiez que l’Object Lock empêche la purge.
Cost/Perf	Erasure coding : choisir `EC:N/2` (ex. 8 nœuds → EC:4) pour l’équilibre capacité / redondance.

Points de vigilance

1. Object Lock rétroactif

Les objets doivent être uploadés après l’activation du lock pour être protégés.

2. Horloge NTP

Un drift > 5 min peut bloquer ou court-circuiter la rétention.

3. Replicas dégradés

Surveillez mc admin heal ; la réplication n’est pas un rempart contre le bit-rot si vos deux sites partagent le même micro-logiciel buggy.

4. Documentation

Documentez le runbook de restauration ; la pire panne est celle que personne ne sait réparer.

Conclusion

Adapter la règle 3-2-1 à un cluster MinIO permet d’obtenir :

Portabilité : API S3 universelle.
Résilience : erasure coding + multi-site active-active.
Immuabilité : Object Lock conforme aux régulations financières.
Souveraineté : déploiement on-prem ou cloud privé, sans dépendance propriétaire.

En quelques commandes, vous disposez ainsi d’un coffre-fort numérique robuste face aux sinistres, aux erreurs et aux rançongiciels.