Etude de cas — Observabilite & sauvegardes
Sauvegardes hybrides Veeam : un « morning check » Grafana qui affiche la cause, pas seulement le statut
Comment j'ai refondu la supervision des sauvegardes d'un SI hybride — trois produits Veeam, InfluxDB, Grafana — et mene la campagne de remediation que cette visibilite a rendue possible.
- 3
- produits Veeam reunis dans un seul dashboard
- 1
- page : si la ligne de synthese est verte, le check est termine
- 326
- objets fantomes purges d'un warning vieux de trois ans
- 196
- boites partagees remises en protection
Le contexte
Un organisme de formation professionnelle multi-sites sauvegarde son SI avec trois produits Veeam : Backup & Replication pour l'on-premise, Backup for Azure pour les VMs cloud, Backup for Microsoft 365 pour Exchange, SharePoint, OneDrive et Teams. La telemetrie remonte vers InfluxDB via des collecteurs shell open source, et s'affiche dans une dizaine de dashboards Grafana distincts.
Probleme : le controle matinal exigeait d'ouvrir plusieurs dashboards, aucun n'affichait la cause des anomalies (il fallait ouvrir les consoles Veeam pour chaque warning), un bug de mapping inversait succes et echecs M365, et six warnings tournaient en boucle — dont un job en warning permanent depuis trois ans, accumule jusqu'a 537 objets en echec.
La demarche
- 01
Audit de l'existant
J'ai analyse les 18 exports JSON Grafana : structure, requetes Flux, mappings. Constats : 3 dashboards en doublon strict (verifie par empreinte md5), un mapping de statuts M365 inverse dans le check matinal historique, des KPIs comptant les sessions plutot que le dernier etat de chaque job, et deux paires de collecteurs en doublon dans le cron.
- 02
Dashboard unique « as code »
J'ai genere un dashboard morning check par script Python : panels, requetes Flux et seuils construits programmatiquement, JSON valide avant import. Principes de conception : compter le dernier etat de chaque job et non les sessions ; detecter les jobs « muets » (aucune execution depuis plus de 26 h — l'angle mort classique : un job plante ne genere ni echec ni warning) ; agreger les trois produits dans une ligne de synthese unique ; afficher l'age de la derniere execution avec seuils colores.
- 03
Faire remonter la cause
Les collecteurs open source ne poussaient que le statut. J'ai ecrit des patchs Bash (idempotents, backup automatique, validation syntaxique avant ecrasement, abandon si points d'ancrage non reconnus) interrogeant les API REST Veeam — detail des sessions et log items cote M365, endpoint de log des sessions cote Azure, message complet cote B&R — et ecrivant la cause en tag InfluxDB, tronquee pour maitriser la cardinalite. Le dashboard gagne une colonne « Message » : le statut et sa cause sur la meme page.
- 04
Un piege InfluxDB au passage
Reecrire l'historique avec un tag supplementaire cree des series paralleles — le tag fait partie de la cle de serie — et rend le « dernier etat » non deterministe. Resolution : purge ciblee de la measurement concernee puis repeuplement complet par le collecteur patche.
- 05
Remediation guidee par les messages
Chaque warning enfin lisible a livre sa cause :
- Une permission Microsoft Graph manquante sur l'app registration Entra ID excluait silencieusement les canaux Teams prives des sauvegardes — corrige (permission + admin consent).
- Le job en warning depuis trois ans pointait des centaines d'objets fantomes : boites partagees recreees en masse avec de nouveaux identifiants (donc absentes des sauvegardes depuis l'evenement) et ex-collaborateurs devenus invites externes. Assainissement en deux passes PowerShell (classification contre l'annuaire, controle des homonymes, dry-run systematique avant modification) : 326 objets purges, dont 196 boites partagees reassociees et remises en protection.
- Deux fichiers utilisateurs bloquants identifies nommement (un script marque par l'antivirus SharePoint, un PST illisible) et traites.
- Un snapshot applicatif de controleur de domaine en echec biquotidien — voir l'encadre cause racine ci-dessous.
- 06
Industrialisation et tracabilite
Rationalisation du cron (collecteurs doublons desactives de facon reversible), suppression des dashboards doublons, rotation du secret InfluxDB expose pendant le diagnostic, et redaction du changement ITIL complet dans l'outil ITSM : analyse d'impacts et de risques, plan de retour arriere, checklist de controle.
L'architecture
Les resultats
- Le check matinal passe de plusieurs consoles a une page : si la ligne de synthese est verte, le controle est termine
- La cause de chaque anomalie est lisible sans ouvrir une console Veeam
- Deux trous de protection silencieux decouverts et corriges : canaux Teams prives exclus des sauvegardes, ~196 boites partagees non protegees depuis une recreation en masse
- Un warning vieux de trois ans (jusqu'a 537 objets en echec) eteint : 326 objets fantomes purges, perimetre final propre
- Une cause racine EDR/BCD demontree par reproduction minimale, avec dossier d'arbitrage remis a la securite
- Outillage reutilisable : dashboard regenerable par script, patchs de collecteurs idempotents avec retour arriere, methodologie dry-run avant toute modification de production
Competences mises en oeuvre
- Grafana (dashboards as code)
- InfluxDB / Flux (modele de series, cardinalite)
- Veeam B&R / Backup for Azure / Backup for M365
- API REST Veeam
- Bash (patchs idempotents)
- PowerShell (modules Veeam, remediation en masse avec dry-run)
- Entra ID (app registrations, permissions Graph)
- Microsoft 365 (Exchange Online, SharePoint, OneDrive, Teams)
- Windows internals (VSS, BCD, WMI)
- Interoperabilite EDR/sauvegarde
- ITIL (changement documente, plan de retour arriere)
- Observabilite
Vos sauvegardes meritent mieux qu'un statut vert
Audit, supervision unifiee, remediation guidee par les causes : parlons de votre contexte.