Sauvegarde et reprise après sinistre
Pour atteindre un objectif de temps de reprise (RTO) et un objectif de point de reprise (RPO) fiables, l'architecture utilise une stratégie de reprise après sinistre à double couche : une couche protège le cluster OpenShift actif, l'autre protège le niveau des VM externes.
Objectifs et matrice de couverture
Les cibles sont ajustées par client ; le tableau ci-dessous constitue la référence de base.
| Composant | Méthode | Fréquence | RPO (référence) |
|---|---|---|---|
| PostgreSQL | Complète + incrémentielle + instantané de VM | WAL continu + complète quotidienne | ≤ 5 min |
| OpenBao / moteur de secrets | Instantané Raft | Toutes les heures | ≤ 1 h |
| État applicatif (PV) | Instantané CSI Velero | Quotidien | ≤ 24 h |
| Manifestes / configuration K8s | Sauvegarde des métadonnées Velero | Quotidien | ≤ 24 h |
| GitLab (source) | Sauvegarde intégrée | Quotidien | ≤ 24 h |
| Matériel HSM | Reste dans le HSM (répliqué selon le fournisseur) | s/o | s/o |
| Scénario | RTO cible (référence) |
|---|---|
| Défaillance d'un pod / nœud isolé | Automatique, en quelques secondes (auto-réparation) |
| Restauration d'un composant avec état | < 1 heure |
| Basculement complet du site (cluster secondaire) | < 4 heures |
Cycle de vie de la reprise après sinistre
Couche 1 — Opérations de sauvegarde (cluster actif)
- Orchestration — l'opérateur Velero exécute des instantanés planifiés et automatisés à l'intérieur du cluster OpenShift.
- État des données — Velero se coordonne avec ODF ou le plugin CSI pour prendre des instantanés de blocs cohérents après crash des volumes soutenant les charges de travail avec état.
- Manifestes et métadonnées — Velero capture simultanément les objets de l'API Kubernetes : namespaces, ServiceAccounts et applications ArgoCD.
- Cible — toutes les métadonnées de sauvegarde et les charges utiles des volumes sont chiffrées et écrites hors du cluster dans un stockage objet compatible S3.
# Exemple : une sauvegarde planifiée quotidienne du namespace duokey
velero schedule create duokey-daily \
--schedule="0 2 * * *" \
--include-namespaces duokey \
--snapshot-volumes
Couche 2 — Sauvegarde de l'infrastructure (VM externes)
- OpenBao — sauvegardé indépendamment en déclenchant des instantanés de stockage Raft automatisés. Les fichiers d'instantanés chiffrés sont stockés hors nœud dans un stockage objet.
- GitLab — utilise ses tâches de sauvegarde intégrées pour archiver les dépôts, les bases de données et la configuration dans un stockage objet.
- PostgreSQL — en tant que couche de données la plus critique, il utilise plusieurs méthodes complémentaires : instantanés de VM ainsi que des sauvegardes de base de données complètes et incrémentielles planifiées.
# Instantané Raft OpenBao (à titre indicatif)
bao operator raft snapshot save openbao-$(date +%F).snap
Procédures de reprise (site secondaire / passif)
En cas de défaillance catastrophique affectant le cluster actif :
- Provisionner le cluster cible — activer ou initialiser un cluster OpenShift secondaire et minimal dans le site de reprise / la zone de disponibilité.
- Restaurer le moteur de secrets — l'instance OpenBao secondaire se déverrouille et charge l'instantané Raft répliqué, restaurant les capacités de gestion des clés.
- Exécuter la restauration Velero — Velero se connecte au stockage objet répliqué dans le site de reprise et exécute une restauration globale.
- Regonfler les volumes — le pilote CSI restaure les instantanés de blocs et les lie aux pods StatefulSet PostgreSQL et Redis nouvellement créés.
- Réconciliation GitOps — ArgoCD se reconnecte à GitLab via HTTPS/SSH, analyse les manifestes et réconcilie toute dérive pour rétablir la conformité.
- Restaurer PostgreSQL — restaurer à partir de la dernière sauvegarde de base de données dans le stockage objet, ou se rabattre sur un instantané complet de VM si les sauvegardes ne peuvent pas être rejouées.
# Restaurer à partir de la sauvegarde Velero la plus récente
velero restore create --from-backup duokey-daily-<timestamp>
Tester votre plan de reprise après sinistre
N'attendez pas un sinistre réel
Répétez la procédure de reprise à intervalles réguliers (au moins trimestriellement). Vérifiez que les cibles RTO/RPO sont réellement atteintes et que les runbooks sont à jour.
| Élément | Fréquence |
|---|---|
| Vérifier que les sauvegardes ont abouti | Quotidien (alerte automatisée) |
| Test de restauration (composant unique) | Mensuel |
| Répétition complète du basculement de reprise | Trimestriel |
| Révision des cibles RTO/RPO | Annuel |