Sauvegarde et Résilience (GLPI)

1. Contexte et Objectifs

Dans le cadre de l'exploitation du serveur GLPI de Solutech, j'ai dû mettre en place une stratégie de sauvegarde robuste. L'objectif était de garantir que les données (tickets, inventaire, configurations) puissent être restaurées rapidement en cas de sinistre (panne, erreur humaine ou cyberattaque).

2. Besoins identifiés

• Automatisation : Le processus ne doit pas dépendre d'une action humaine quotidienne.

• Sécurité (Privilèges restreints) : Utiliser un compte dédié uniquement à la sauvegarde.

• Traçabilité : Disposer d'un journal (log) pour vérifier le succès ou l'échec des opérations.

• Gestion de l'espace (Rétention) : Éviter la saturation du disque en ne gardant que les versions récentes.

• Preuve de restauration : Certifier que les fichiers de sauvegarde sont exploitables.

3. Solution technique

• MariaDB/MySQL Dump : Pour l'extraction à chaud de la base de données glpidb.

• Tar (Gzip) : Pour la compression du patrimoine de fichiers (fichiers de conf, documents joints).

• Bash Scripting : Pour l'industrialisation des commandes de sauvegarde.

• Logrotate : Pour la gestion automatique de la rétention et de la rotation des archives.

• Cron : Pour la planification automatique du script chaque nuit.

• La Sécurité des Mots de Passe (Hash)

Lors de la vérification de mon compte cassandre-sauvegarde, j'ai pu observer que les mots de passe ne sont pas stockés en clair mais sous forme de Hash (empreinte numérique). C'est un principe de sécurité fondamental : même en cas de vol de la base mysql, le mot de passe original reste indéchiffrable.

4. Réalisation

• Création du compte de maintenance : Mise en place de l'utilisateur SQL cassandre-sauvegarde avec les droits minimaux (SELECT, LOCK TABLES).

• Configuration locale (.my.cnf) : Création d'un fichier de configuration sécurisé en chmod 600 pour permettre au script de se connecter sans saisir de mot de passe en clair.

• Écriture du script backup_solutech.sh : Inclusion de la gestion des erreurs ($?) et de l'écriture dans un fichier log dédié (/var/log/backup_solutech.log).

#!/bin/bash
# =====================================================================
# NOM : backup_solutech.sh
# ROLE : Automatisation de la sauvegarde (SQL + Filesystem)
# AUTEUR : Cassandre
# =====================================================================

# 1. DÉFINITION DES VARIABLES
DATE=$(date +%F_%H-%M)
DEST="/home/glpi/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
# On s'assure que le dossier de destination existe avec les bons droits
mkdir -p $DEST
chown glpi:glpi $DEST

echo "--- DÉBUT DE LA SAUVEGARDE : $DATE ---" >> $LOG_FILE

# 3. SAUVEGARDE SQL (Utilise le fichier ~/.my.cnf pour l'authentification)
# --single-transaction permet de ne pas bloquer la base pendant la sauvegarde
mysqldump $DB_NAME --single-transaction > $DEST/dbglpi.sql

# Gestion de l'erreur ($?) pour le dump 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 (Archivage compressé .tar.gz)
tar -czf $DEST/glpi_config_files.tar.gz $SRC_GLPI $SRC_CONFIG $SRC_APACHE

# Gestion de l'erreur ($?) pour l'archivage
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 MISSION ---" >> $LOG_FILE

• Mise en place de la rétention via Logrotate avec la directive rotate 2. Cela permet de conserver un cycle de 3 exemplaires par type de fichier (1 actif + 2 historiques). Ainsi, le dossier backups ne contiendra jamais plus de 6 fichiers au total, garantissant la maîtrise de l'espace disque.

• Planification : Automatisation via la crontab pour une exécution quotidienne.

• Test de Restauration (Disaster Recovery) : Simulation d'une perte totale des données (DROP DATABASE et rm -rf) suivie d'une restauration réussie à partir des archives.

5. Preuves de réalisation

Capture du résultat de la commande tar -tvf montrant le contenu détaillé de mon archive de configuration

Capture de la ligne de commande mysqldump exécutée avec cassandre-sauvegarde suivie d'un ls -lh confirmant que le fichier créé n'est pas vide

Capture du résultat de la requête SQL SELECT user,password FROM mysql.user; montrant l'existence de mon compte de maintenance nominatif et mon mot de passe haché

Capture montrant le contenu du dossier /home/glpi/backups (ls -lh) ET le contenu de mon fichier de log pro /var/log/backup_solutech.log

Capture du résultat de la rotation après mes cycles de test. Sur cette capture, on observe la présence de 4 fichiers de sauvegarde (2 dumps SQL et 2 archives compressées). Ce résultat valide le fonctionnement de Logrotate avec la directive rotate 2 : le système conserve l'archive active ainsi que les 2 versions historiques les plus récentes pour chaque type de ressource, avant de supprimer automatiquement les suivantes pour préserver l'espace disque

Capture du résultat de la commande crontab -l prouvant que le robot de sauvegarde est programmé pour s'exécuter seul

Capture de la sauvegarde cron automatique effectuée

Capture de l'interface GLPI après la suppression de la base de données

Capture de l'interface GLPI après la restauration, montrant l'historique datant d'avant la suppression de la base de données.