💾 Gestion des sauvegardes et de la résilience

Compétences du référentiel visées

1.4 — Vérifier la continuité

Justification :
Mise en œuvre et validation d’une procédure complète de restauration afin de garantir la reprise du service GLPI dans un délai conforme au RTO défini.

1.5 — Gérer les sauvegardes

Justification :
Déploiement d’une solution de sauvegarde automatisée couvrant à la fois la base de données et les fichiers critiques, avec gestion de la rétention, respect du RPO et création d’archives distinctes.

1️⃣ Contexte et objectifs

Dans le cadre de la fusion entre Solutech et Horizon, une CMDB complète a été mise en place dans GLPI. Cette base centralise des données essentielles pour le support informatique, comme les équipements, les tickets, les utilisateurs, les configurations et les informations d’inventaire.

La perte ou l’indisponibilité de ces données représenterait un risque important pour l’activité de l’entreprise. Il était donc nécessaire de mettre en place une stratégie de sauvegarde fiable afin de protéger les données critiques et de garantir une reprise rapide du service en cas d’incident.

L’objectif principal était de sécuriser l’environnement GLPI en s’appuyant sur les notions de RPO et de RTO :

  • le RPO définit la quantité maximale de données pouvant être perdue ;
  • le RTO définit le temps maximal acceptable pour rétablir le service.

La solution devait également respecter la règle de sauvegarde 3-2-1, assurer la traçabilité des actions et être validée par des tests de restauration.

2️⃣ Besoins identifiés

Les besoins suivants ont été identifiés :

  • protéger les données critiques de la CMDB ;
  • garantir la disponibilité du service GLPI en cas d’incident ;
  • définir une perte de données maximale acceptable avec le RPO ;
  • définir un temps de reprise maximal avec le RTO ;
  • mettre en place une stratégie de sauvegarde fiable, automatisée et sécurisée ;
  • appliquer la règle de sauvegarde 3-2-1 ;
  • assurer la traçabilité et l’imputabilité des actions réalisées ;
  • sécuriser les accès aux opérations de maintenance et de sauvegarde ;
  • vérifier régulièrement le contenu et l’intégrité des sauvegardes ;
  • valider la restauration du service par des tests concrets ;
  • assurer la continuité d’activité en cas de panne, suppression accidentelle ou cyberattaque.

3️⃣ Solution technique retenue et justifications

La solution technique retenue consiste à mettre en place un système de sauvegarde complet du serveur GLPI. Cette solution couvre à la fois la sauvegarde de la base de données et celle des fichiers critiques de l’application.

La base de données GLPI est sauvegardée avec l’outil mysqldump. Cette méthode permet de réaliser une sauvegarde logique complète des données, notamment les tickets, les utilisateurs, l’inventaire, les configurations et les informations de la CMDB.

Les fichiers critiques de GLPI sont archivés avec la commande tar et compressés au format .tar.gz. Les répertoires sauvegardés comprennent les fichiers applicatifs, les fichiers de configuration et les éléments nécessaires au bon fonctionnement du service.

Afin de renforcer la sécurité, un compte de maintenance MariaDB dédié a été créé. Ce compte dispose uniquement des privilèges nécessaires à la sauvegarde, conformément au principe du moindre privilège. Les identifiants ne sont pas inscrits directement dans le script : ils sont stockés dans un fichier .my.cnf sécurisé.

Le processus est automatisé avec un script Bash. Ce script prend en charge :

  • la sauvegarde SQL ;
  • l’archivage des fichiers ;
  • la gestion des erreurs ;
  • l’écriture de logs ;
  • la traçabilité des opérations.

La planification est assurée avec Cron, ce qui permet d’exécuter les sauvegardes régulièrement et automatiquement.

La rétention est gérée avec Logrotate, afin de conserver un nombre maîtrisé de sauvegardes et d’éviter la saturation du stockage.

Enfin, des contrôles ont été réalisés sur les archives afin de vérifier leur présence, leur taille et leur contenu. Des tests de restauration ont également été effectués afin de valider la fiabilité des sauvegardes et le respect du RTO.

4️⃣ Réalisation

Compétences techniques mobilisées

Dans le cadre de cette situation professionnelle, plusieurs compétences techniques ont été mobilisées :

  • administration et utilisation avancée de GLPI ;
  • identification des éléments critiques de l’application ;
  • sauvegarde de fichiers sous Linux avec tar ;
  • sauvegarde de base de données avec mysqldump ;
  • création et sécurisation d’un compte de maintenance MariaDB ;
  • automatisation de tâches avec un script Bash ;
  • planification des sauvegardes avec Cron ;
  • gestion de la rétention avec Logrotate ;
  • consultation et analyse de logs ;
  • application des principes ITIL liés à la continuité de service.

Script de sauvegarde automatisé

Pour automatiser le processus de sauvegarde, un script Bash a été développé. Il permet de sauvegarder la base de données GLPI ainsi que les fichiers critiques du serveur.

#!/bin/bash
# =====================================================================
# NOM : backup_solutech.sh

# 1. Définition des variables
DATE=$(date +%F_%H-%M)
DEST="/home/servglpi/backups"
DB_NAME="glpidb"
LOG_FILE="/var/log/backup_solutech.log"

# Liste des dossiers à archiver
SRC_GLPI="/var/www/html/glpi/files"
SRC_CONFIG="/var/www/html/glpi/config"
SRC_APACHE="/etc/apache2/sites-available"

# 2. Préparation de l’environnement
mkdir -p $DEST
chown servglpi:servglpi $DEST
echo "--- DÉBUT DE LA SAUVEGARDE : $DATE ---" >> $LOG_FILE

# 3. Sauvegarde de la base de données
mysqldump $DB_NAME --single-transaction > $DEST/dbglpi.sql

if [ $? -eq 0 ]; then
    echo "[$DATE] SUCCESS: Dump SQL réalisé avec succès." >> $LOG_FILE
else
    echo "[$DATE] ERROR: Échec du dump SQL. Vérifiez les droits." >> $LOG_FILE
    exit 1
fi

# 4. Sauvegarde des fichiers
tar -czf $DEST/glpi_config_files.tar.gz $SRC_GLPI $SRC_CONFIG $SRC_APACHE

if [ $? -eq 0 ]; then
    echo "[$DATE] SUCCESS: Archivage des fichiers terminé." >> $LOG_FILE
else
    echo "[$DATE] ERROR: Échec de l'archivage." >> $LOG_FILE
    exit 1
fi

echo "--- FIN DE LA SAUVEGARDE ---" >> $LOG_FILE

Travail réalisé

Les actions suivantes ont été réalisées :

identification des éléments critiques du serveur GLPI ; analyse des fichiers de configuration afin d’identifier la base de données et les accès associés ; sauvegarde des fichiers GLPI avec tar ; compression et création d’archives au format .tar.gz ; vérification de la taille et du contenu des archives ; sauvegarde de la base de données avec mysqldump ; création d’un compte de maintenance MariaDB avec des privilèges limités ; sécurisation des identifiants via un fichier .my.cnf ; validation de la base de données à l’aide de requêtes SQL ; développement d’un script Bash automatisant les sauvegardes SQL et fichiers ; mise en place de logs pour assurer la traçabilité ; ajout d’une gestion des erreurs dans le script ; configuration de Cron pour planifier les sauvegardes ; configuration de Logrotate pour gérer la rétention ; vérification du bon fonctionnement de l’automatisation via les logs ; simulation d’un incident majeur avec perte de fichiers et de base de données ; restauration complète du service GLPI à partir des sauvegardes ; vérification de l’intégrité des données après restauration ; validation de la disponibilité du service après reprise ; application de la règle de sauvegarde 3-2-1.

Résultats obtenus

La solution mise en place permet de sécuriser efficacement les données critiques du serveur GLPI. Les sauvegardes sont désormais automatisées, régulières et vérifiables, ce qui réduit fortement le risque de perte de données.

L’utilisation d’un script Bash et d’une planification Cron permet de limiter les interventions manuelles et donc de réduire les erreurs humaines. Cette automatisation contribue également au respect du RPO, puisque les sauvegardes sont réalisées selon une fréquence définie.

La gestion de la rétention avec Logrotate permet de maîtriser l’espace disque utilisé par les sauvegardes. Elle évite l’accumulation excessive d’archives et limite le risque de saturation du serveur.

La sécurité a également été renforcée grâce à la création d’un compte de maintenance dédié et à l’utilisation d’un fichier .my.cnf pour stocker les identifiants de manière plus sûre.

Enfin, les tests de restauration ont confirmé la fiabilité des sauvegardes. Le service GLPI a pu être restauré correctement, les données ont été vérifiées et le temps de reprise est resté conforme au RTO défini.

Preuves de réalisation

Vérification de l’archive de configuration

Une première capture d’écran présente le résultat de la commande permettant de vérifier le contenu de l’archive de configuration. On y observe notamment la présence du fichier config_db.php, qui contient les informations de connexion à la base de données GLPI.

Cette vérification permet de confirmer que l’archive contient bien les fichiers nécessaires à une future restauration.

Vérification de la sauvegarde SQL

Une deuxième capture d’écran présente le résultat des commandes mysqldump et ls -lh. Ces commandes permettent de vérifier la création d’un nouveau fichier de sauvegarde et de contrôler sa taille.

Cette étape permet également de s’assurer que l’action de sauvegarde est bien réalisée par le compte prévu, ce qui contribue à l’imputabilité et à la traçabilité des opérations.

Vérification du compte de maintenance

Une autre capture d’écran présente une requête SQL permettant de vérifier la présence du compte de maintenance dédié aux sauvegardes, ainsi que l’existence de son mot de passe stocké sous forme hashée dans la base de données.

Cette vérification confirme que le compte technique a bien été créé et qu’il peut être utilisé pour les opérations de sauvegarde dans un cadre sécurisé.

Vérification du contenu d’une archive

Cette capture montre la vérification d’une archive de sauvegarde au format .tar.gz.

Vérification du contenu de l’archive GLPI

La commande ls -lh permet de confirmer la présence du fichier de sauvegarde et sa taille.

La commande tar -tvf permet de lister le contenu de l’archive sans l’extraire, afin de vérifier que les fichiers de GLPI ont bien été sauvegardés.

Cette étape est importante dans une démarche de résilience, car elle permet de s’assurer que les données nécessaires à une restauration sont bien présentes.