Aller au contenu

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

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 operational
  • ccx-ops backup full
  • ccx-ops prune
  • ccx-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