Operations Backups¶
Les sauvegardes constituent un mécanisme essentiel de protection de CMonChoix Platform.
Elles garantissent la capacité à restaurer un état cohérent de la Platform après un incident, une erreur humaine, une régression ou une évolution ayant produit un résultat inattendu.
Une sauvegarde n'est pas uniquement une copie des données.
Elle représente une garantie de continuité d'exploitation.
Objectifs¶
La politique de sauvegarde poursuit plusieurs objectifs.
- protéger les données de la Platform ;
- limiter les pertes d'information ;
- permettre un retour arrière maîtrisé ;
- faciliter les opérations de maintenance ;
- sécuriser les évolutions importantes.
Une sauvegarde n'est utile que si elle peut être restaurée de manière fiable.
Position dans l'architecture¶
Les sauvegardes concernent plusieurs couches de la Platform.
Backups
│
┌─────────┼─────────┐
│ │ │
Database Runtime Configuration
│
└────── Documentation
Chaque composant possède ses propres besoins de sauvegarde.
Principes¶
La stratégie de sauvegarde repose sur plusieurs principes.
Prévention¶
Une sauvegarde est réalisée avant une opération présentant un risque.
Elle ne remplace pas les validations.
Elle constitue un mécanisme de sécurité.
Intégrité¶
Une sauvegarde doit représenter un état cohérent de la Platform.
Une copie partielle ou incohérente ne peut pas être considérée comme exploitable.
Traçabilité¶
Chaque sauvegarde importante doit être identifiable.
Les informations associées comprennent notamment :
- la date ;
- le contexte ;
- le périmètre ;
- la raison de la sauvegarde.
Restaurabilité¶
Une sauvegarde doit pouvoir être restaurée.
Une sauvegarde jamais testée ne garantit pas la reprise de la Platform.
Éléments sauvegardés¶
Plusieurs catégories d'informations peuvent être protégées.
Base de données¶
Les données persistées représentent le principal patrimoine informationnel de la Platform.
Leur sauvegarde garantit la possibilité de restaurer un état cohérent.
Configuration¶
Les éléments de configuration nécessaires au fonctionnement de la Platform doivent être conservés.
Ils permettent de reconstruire un environnement identique.
Documentation¶
La documentation fait partie intégrante de l'architecture.
Elle accompagne les procédures de restauration et les évolutions de la Platform.
Ressources techniques¶
Selon les besoins, d'autres ressources peuvent également être sauvegardées.
Par exemple :
- fichiers techniques ;
- scripts d'exploitation ;
- configurations Runtime.
Cycle de sauvegarde¶
Une opération de sauvegarde suit généralement le processus suivant.
Préparation
│
▼
Sauvegarde
│
▼
Validation
│
▼
Archivage
│
▼
Disponibilité
Chaque étape garantit la qualité de la sauvegarde produite.
Vérification¶
Une sauvegarde doit être contrôlée.
Les vérifications portent notamment sur :
- son intégrité ;
- sa complétude ;
- son accessibilité ;
- sa capacité à être restaurée.
Une sauvegarde invalide ne protège pas la Platform.
Utilisation¶
Les sauvegardes interviennent notamment dans les situations suivantes.
Avant une évolution¶
Une modification importante de la Platform peut nécessiter un retour arrière.
Une sauvegarde est réalisée avant l'intervention.
Avant une migration¶
Une migration de données est précédée d'une sauvegarde permettant de retrouver l'état initial si nécessaire.
Avant une reconstruction¶
Certaines reconstructions importantes peuvent justifier une sauvegarde préalable.
Après validation¶
Une fois une évolution validée, une nouvelle sauvegarde peut être réalisée afin de conserver un nouvel état de référence.
Dépendances¶
La stratégie de sauvegarde concerne plusieurs composants.
- Database
- Runtime
- Configuration
- Documentation
- outils d'exploitation
Les sauvegardes n'interviennent jamais dans la logique métier.
Invariants¶
Les sauvegardes respectent plusieurs propriétés fondamentales.
Une sauvegarde est cohérente¶
Elle représente un état complet de la Platform.
Une sauvegarde est identifiable¶
Son contexte de création reste documenté.
Une sauvegarde est restaurable¶
Sa restauration est techniquement possible.
Une sauvegarde est indépendante¶
Elle reste exploitable même si la Platform évolue ultérieurement.
Garde-fous¶
Afin de garantir une protection efficace, plusieurs règles doivent toujours être respectées.
Ne jamais :
- considérer une copie non vérifiée comme une sauvegarde valide ;
- écraser une sauvegarde importante sans politique définie ;
- effectuer une évolution majeure sans sauvegarde préalable ;
- supposer qu'une restauration fonctionnera sans l'avoir vérifiée ;
- confondre sauvegarde et archivage.
Vision long terme¶
À mesure que CMonChoix Platform évoluera, la stratégie de sauvegarde s'enrichira progressivement afin de :
- automatiser certaines opérations ;
- renforcer les contrôles d'intégrité ;
- améliorer les procédures de restauration ;
- réduire le temps de reprise ;
- garantir une meilleure résilience de la Platform.
La sauvegarde restera néanmoins guidée par le même objectif fondamental : préserver durablement les actifs techniques et fonctionnels de CMonChoix Platform.
Politique de sauvegarde¶
Objectifs¶
CMonChoix distingue deux types de sauvegardes :
- sauvegarde opérationnelle ;
- sauvegarde complète.
Cette séparation permet de réduire fortement le temps de sauvegarde quotidien tout en conservant la possibilité de réaliser des sauvegardes exhaustives lorsque cela est nécessaire.
Sauvegarde opérationnelle¶
Commande :
ccx-backup operational
Utilisation :
- avant un développement ;
- avant une synchronisation importante ;
- avant une migration ;
- sauvegarde quotidienne.
Contenu :
- base MariaDB (hors tables temporaires volumineuses) ;
- documentation MkDocs ;
- rapport d'exécution.
La table suivante est volontairement exclue :
wp_ccx_sync_stage_raw_v2
Cette table contient uniquement des données de transit pouvant être régénérées.
Le temps de sauvegarde est ainsi fortement réduit.
Sauvegarde complète¶
Commande :
ccx-backup full
Utilisation :
- avant une mise à jour majeure ;
- avant une modification de structure ;
- avant une migration serveur ;
- archivage.
Aucune table n'est exclue.
Rotation¶
Commande :
ccx-backup-prune
Politique actuelle :
| Type | Conservation |
|---|---|
| Operational | 7 |
| Full | 3 |
| Documentation | 14 |
| Rapports | 30 |
Point d'entrée¶
Toutes les opérations passent par :
ccx-ops
Exemples :
ccx-ops health
ccx-ops backup
ccx-ops backup-full
ccx-ops prune
ccx-ops daily
Invariants¶
Les scripts d'exploitation :
- ne contiennent aucun mot de passe en dur ;
- utilisent la bibliothèque commune :
/usr/local/lib/ccx/common.sh
Les informations MariaDB sont récupérées automatiquement depuis l'environnement du conteneur WordPress.
Aucun script ne duplique ces informations.
Bonnes pratiques¶
Avant toute opération importante :
ccx-ops health
Avant toute modification de code :
ccx-ops backup
Après validation :
ccx-backup-prune
Voir aussi¶
- Operations Overview
- Operations Maintenance
- Operations Recovery
- Operations Deployment
- Operations Incidents
- Database Overview
- Architecture Vision
Vérification¶
Une sauvegarde doit être vérifiable sans restaurer la base en production.
La commande suivante contrôle qu'un backup SQL compressé est lisible :
ccx-ops verify /mnt/data/backups/sql/<backup>.sql.gz
Cette commande vérifie :
- l'intégrité gzip ;
- la présence de l'en-tête MariaDB ;
- un échantillon des tables du dump.
Elle ne modifie aucune donnée.
Implémentation serveur actuelle¶
Les sauvegardes opérationnelles sont pilotées par :
ccx-ops backup operationalccx-ops backup fullccx-ops pruneccx-ops verify /mnt/data/backups/sql/<backup>.sql.gz
Deux niveaux existent :
| Type | Commande | Usage |
|---|---|---|
| Opérationnel | ccx-backup operational |
Backup quotidien léger |
| Complet | ccx-backup full |
Backup complet avant opération importante |
Le backup opérationnel exclut les tables de staging volumineuses lorsque cela est nécessaire afin de rester rapide et exploitable.
Les backups Docker sont réalisés via :
ccx-ops docker-backup
Ils couvrent notamment :
- inspections des conteneurs ;
- informations Docker ;
- volumes Docker ;
- configuration système utile ;
- données Portainer/NPM lorsque présentes.
La capacité globale de restauration est vérifiée avec :
ccx-ops restore-check
Un état sain retourne :
RESTORE_CHECK_STATUS=OK