Protection-et-Resilience

1. Contexte et Objectifs

Mise en place d'une stratégie de sauvegarde et de résilience pour l'entreprise Solutech. Garantir la continuité de service en protégeant les données vitales (base de données GLPI, fichiers applicatifs et configuration Apache) contre toute perte accidentelle ou incident critique.

2. Besoins identifiés

Identification des données vitales à sauvegarder (base MariaDB, fichiers GLPI, configuration Apache), création d'un compte de maintenance sécurisé avec le principe du moindre privilège, automatisation des sauvegardes via un script Bash industrialisé, mise en place d'une politique de rétention pour éviter la saturation du stockage, et validation de la résilience par un test de restauration réel.

3. Solution technique

Utilisation de mysqldump pour l'extraction de la base de données MariaDB, de tar pour l'archivage compressé des fichiers applicatifs, d'un compte MariaDB dédié (glpi-sauvegarde) avec privilèges restreints en lecture seule, de Logrotate pour la gestion de la rétention des archives, et de Cron pour la planification automatique des sauvegardes.

4. Réalisation

• Sauvegarde du système de fichiers : archivage compressé des dossiers /var/www/html/glpi/files, /var/www/html/glpi/config et /etc/apache2/sites-available via tar.

• Extraction de la base de données : dump complet de la base glpidb en mode root puis via le compte de maintenance glpi-sauvegarde avec l'option --single-transaction.

• Création du compte de maintenance : utilisateur MariaDB nominatif avec privilèges SELECT, SHOW VIEW, TRIGGER, LOCK TABLES et EVENT uniquement, et fichier .my.cnf sécurisé (chmod 600) pour éviter tout mot de passe en clair dans les scripts.

• Industrialisation par script Bash : script backup_solutech.sh structuré autour du shebang, de variables, et de la gestion des erreurs ($?), produisant des logs horodatés dans /var/log/backup_solutech.log.

• Gestion de la rétention via Logrotate : politique de rotation configurée pour conserver 2 archives historiques, garantissant 3 points de restauration (1 actif + 2 historiques) sans saturation du stockage.

• Planification automatique via Cron : tâche programmée pour déclencher le script de sauvegarde de façon autonome et régulière.

• Test de restauration (Disaster Recovery) : simulation d'un crash et restauration complète de l'instance GLPI pour valider la résilience de l'infrastructure.

5. Preuves de réalisation

Contrôle d'intégrité des archives

Figure 1 : Résultat de la commande tar -tvf affichant le contenu détaillé de l'archive de configuration — le fichier config_db.php est visible dans la liste.

Extraction SQL avec le compte de maintenance

Figure 2 : Commande mysqldump exécutée avec l'utilisateur glpi-sauvegarde suivie d'un ls -lh confirmant que le fichier généré n'est pas vide.

Vérification de l'utilisateur MariaDB

Figure 3 : Résultat de la requête SELECT user, password FROM mysql.user; montrant l'existence du compte de maintenance nominatif et son mot de passe haché.

Industrialisation et journalisation

Figure 4 : Contenu du dossier /home/glpi/backups (ls -lh) et extrait du fichier de log /var/log/backup_solutech.log — on distingue une trace d'échec et une trace de succès.

Rétention système via Logrotate

Figure 5 : Résultat de la rotation après les cycles de test — 3 fichiers SQL visibles (1 actif + 2 archives historiques datées par Logrotate).

Planification automatique via Cron

Figure 6 : Résultat de la commande crontab -l prouvant que le robot de sauvegarde est programmé pour s'exécuter automatiquement.

Preuve de résilience après restauration

Figure 7 : Interface GLPI après restauration complète — l'onglet "Historique" d'un ordinateur affiche des modifications datant d'avant le crash simulé, prouvant la résilience de l'infrastructure.