4 La surveillance des sauvegardes est souvent reléguée au second plan. On configure les tâches et on suppose qu’elles fonctionnent. Jusqu’au jour où une restauration est nécessaire et où l’on découvre des échecs remontant à plusieurs semaines, ou des données corrompues. Pour les responsables de l’IA et du ML, la surveillance est essentielle. Les données d’entraînement et les artefacts de modèles sont irremplaçables. Des sauvegardes en échec peuvent faire reculer des pipelines entiers de plusieurs semaines. Vous devez avoir la certitude que les sauvegardes se terminent, que les données sont protégées et que la restauration est possible. Les bonnes pratiques de surveillance des sauvegardes garantissent la bonne santé de votre infrastructure. Cet article explique quoi surveiller, comment structurer les alertes, comment s’intégrer à l’observabilité MLOps et comment garantir la capacité de reprise. Quoi surveiller La surveillance des sauvegardes couvre plusieurs niveaux critiques : Achèvement des tâches : la sauvegarde se termine-t-elle correctement dans les fenêtres prévues (par exemple de 22 h à 4 h) ? Alertez en cas d’échec et de tâches dépassant leur fenêtre. Intégrité des données : la sauvegarde a-t-elle réellement protégé les données ? Vérifiez que les données sauvegardées sont lisibles, non corrompues et identiques à la source. Utilisez des sommes de contrôle ou une vérification par hachage. Performances : à quelle vitesse les sauvegardes se terminent-elles ? Des sauvegardes qui prennent 6 heures au lieu de 2 signalent une dégradation. Le suivi des tendances de performance permet d’identifier les problèmes avant les échecs. Surveillez les contraintes de ressources, les problèmes réseau et les inefficacités de configuration. Capacité : quelle quantité de stockage est utilisée ? Une croissance plus rapide que prévu indique que l’on approche des limites. Suivez le taux d’utilisation et les rythmes de croissance. Réseau et E/S : quelle bande passante et quelles E/S disque les sauvegardes consomment-elles ? Une consommation excessive suggère une charge inutile. Une bande passante insuffisante peut constituer un goulot d’étranglement. Déduplication : si vous utilisez la déduplication, surveillez les ratios. Un passage de 10:1 à 5:1 signale un problème. Rétention et suppression : les anciennes sauvegardes sont-elles supprimées conformément à la politique ? Suivez le nombre de sauvegardes à chaque niveau (chaud, tiède, froid). Signalez toute suppression qui n’a pas lieu comme prévu. Structurer efficacement les alertes Utilisez des alertes hiérarchisées : Critique : échec de sauvegarde, problème d’accès au stockage, défaut d’intégrité des données. Exige une investigation immédiate, en quelques minutes. Appelez l’astreinte. Avertissement : dégradation des performances (50 % plus lent que la référence), capacité proche des limites (80 %), problèmes de déduplication. Exige une investigation dans les heures qui suivent, pendant les heures ouvrées. Information : événements de routine — fin de tâche réussie, hiérarchisation planifiée, suppressions liées à la rétention. À journaliser, sans appel ni ticket. Évitez la lassitude face aux alertes. Si les équipes reçoivent 50 alertes par jour dont seulement 5 sont critiques, elles finiront par toutes les ignorer. Soyez sélectif. Alertez sur des situations qui appellent une action, pas sur des événements de routine. S’intégrer à l’observabilité MLOps La surveillance des sauvegardes doit s’intégrer aux piles d’observabilité existantes. Votre infrastructure MLOps utilise probablement Prometheus, Grafana, ELK ou Datadog. Visibilité unifiée : les data scientists doivent voir l’état des sauvegardes sur leurs tableaux de bord. Si des sauvegardes ont échoué ce matin, c’est une information utile. Les tableaux de bord affichent l’état des sauvegardes à côté de celui des entraînements, en cohérence avec les objectifs de RTO et de RPO (en anglais). Alertes partagées : votre système d’alerte MLOps doit signaler les échecs de sauvegarde et les acheminer par les mêmes canaux de réponse aux incidents que les autres problèmes. Métriques corrélées : les E/S de stockage des sauvegardes et l’accès aux données d’entraînement sont liés. Des E/S de sauvegarde intensives peuvent ralentir l’accès aux données. Capturez cette corrélation pour identifier et résoudre les contentions. Suivi de la traçabilité des données : reliez les sauvegardes aux versions de données. « Cette sauvegarde contient les données d’entraînement 2.3, utilisées pour entraîner le modèle 5.1, déployé le [date]. » C’est indispensable pour la reprise : savoir quelles données d’entraînement un modèle a utilisées. Tester la capacité de reprise Le plus important : tester. Une surveillance parfaite ne garantit pas que les sauvegardes sont utilisables. Tests de restauration (en anglais) : au moins une fois par mois, essayez de restaurer des sauvegardes. Vérifiez l’exactitude des données : Structure : les fichiers existent-ils ? Sont-ils lisibles ? Intégrité : les sommes de contrôle correspondent-elles ? Les données sont-elles complètes ? Utilisabilité : votre pipeline ML peut-il traiter les données restaurées ? Tests du temps de reprise : chronométrez la reprise réelle. Si votre RTO est de 4 heures, vérifiez que vous pouvez restaurer les jeux de données en 4 heures, en incluant la localisation, la récupération et la vérification. Tests de basculement : si plusieurs cibles existent, testez la reprise depuis la cible secondaire. Assurez-vous qu’elle fonctionne le moment venu. Exercices de reprise après sinistre : chaque trimestre ou chaque année, simulez la perte des données de production et leur restauration à partir des sauvegardes. Chronométrez la reprise. Documentez les problèmes. Surveiller les scénarios propres à l’IA L’IA introduit des défis de sauvegarde spécifiques : Versioning des jeux de données : suivez quelles versions sont sauvegardées. Facilitez la reprise : « Afficher les versions de jeux de données disponibles et l’état de leur sauvegarde. » Checkpoints de modèles : vérifiez que les checkpoints sont sauvegardés et récupérables. Permettez de reprendre depuis le dernier checkpoint sauvegardé en cas d’interruption de l’entraînement. Dépendances des pipelines : suivez les relations. « Cette sauvegarde contient le jeu de données X et le modèle Y. Le modèle Y requiert les variables A et B issues de X. » Restaurer sans comprendre ces dépendances peut échouer. Pistes d’audit : pour la conformité, vérifiez que les activités de création, de suppression et de restauration des sauvegardes sont journalisées et auditables. Les journaux d’audit doivent être complets, immuables et s’intégrer aux outils SIEM (en anglais). Alerter sur les défaillances cachées Le plus dangereux : les défaillances qui ne déclenchent aucune alerte. Corruption silencieuse : la sauvegarde se termine, mais les données sont corrompues. Des semaines plus tard, la restauration échoue. Prévenez-la en calculant des sommes de contrôle lors de la sauvegarde, en les conservant et en les vérifiant périodiquement (et pas seulement lors de la restauration). Perte des clés de chiffrement : les sauvegardes sont chiffrées, mais les clés sont inaccessibles. Prévenez-la en surveillant la disponibilité des clés, en testant leur récupération et en les conservant séparément. Problèmes d’accès au stockage : identifiants cloud mal configurés, données non stockées. Vérifiez que les écritures réussissent réellement, et pas seulement que la tâche le croit. Défaillances de rétention : les anciennes sauvegardes ne sont pas supprimées conformément à la politique. Le stockage se remplit de façon inattendue. Vérifiez que les tâches de suppression s’exécutent et que le nombre de sauvegardes diminue. Défaillance de la déduplication : la déduplication cesse de fonctionner. La consommation de stockage s’envole. Surveillez l’évolution du ratio de déduplication. Sans surveillance, vous ne le remarquerez que lorsque le stockage sera critique. Surveiller le système de surveillance Votre surveillance doit être fiable. Une défaillance du système signifie une perte de visibilité. Surveillance redondante : combinez plusieurs approches. Principale : la surveillance intégrée du logiciel de sauvegarde (en anglais). Secondaire : des scripts personnalisés qui vérifient les sauvegardes de manière indépendante. Tertiaire : les métriques du fournisseur cloud. Surveiller la surveillance : si la surveillance cesse de remonter des métriques, déclenchez une alerte. Si aucune donnée n’arrive pendant 24 heures alors que des données quotidiennes sont attendues, quelque chose ne va pas. Rétention des journaux : conservez les journaux plus longtemps que les métriques. Enquêter sur une défaillance vieille de trois mois exige des journaux. Stockez-les dans une solution de journalisation centralisée (SIEM, data lakes). Besoins de conformité et d’audit La surveillance doit faciliter les audits de conformité : Exhaustivité de la piste d’audit : les journaux capturent tous les événements pertinents — sauvegarde lancée, réussie, vérifiée, conservée, supprimée. Ces journaux prouvent la conformité. Suivi des modifications : journalisez les changements de politique (rétention allongée, jeux de données ajoutés). Les auditeurs veulent savoir quand et pourquoi ces changements ont eu lieu. Gestion des exceptions : journalisez les sauvegardes en échec et les interventions manuelles. Les auditeurs comprennent les processus manuels et la manière dont les problèmes sont résolus. Conformité de la rétention : vérifiez que les sauvegardes sont conservées pendant les durées requises. Si une rétention de 7 ans est exigée, confirmez que des sauvegardes vieilles de 7 ans existent. Organiser l’exploitation de la surveillance Bien faire exige une discipline opérationnelle : Définir des critères de réussite : « Toutes les tâches se terminent dans la fenêtre prévue. La déduplication maintient un ratio de 4:1. Aucune corruption lors des tests de restauration hebdomadaires. La reprise réussit dans le respect du RTO. » Construire des tableaux de bord : affichez l’état actuel et les tendances, notamment l’état des tâches, le taux d’utilisation de la capacité, le ratio de déduplication, le dernier test de restauration et les alertes critiques. Établir des procédures : pour chaque alerte critique, rédigez : « Alerte : [X]. Procédure : vérifier [Y], puis [Z], puis exécuter [W]. » Cela évite la panique et garantit la cohérence. Mener des revues régulières : chaque semaine ou chaque mois, passez en revue les données de surveillance. Quelque chose tend-il vers la défaillance ? Les restaurations ont-elles révélé des problèmes ? Les seuils sont-ils adaptés ? Planifier la capacité : utilisez les tendances pour planifier la capacité future. Si le stockage croît de 5 To par mois, étendez-le avant d’atteindre 80 % d’utilisation. Éviter l’excès de surveillance Il est possible de trop surveiller. Toutes les métriques ne méritent pas une alerte. Concentrez-vous sur ce qui compte : l’achèvement, l’intégrité des données, la capacité de reprise et la conformité. Tout le reste n’est que détail complémentaire. L’objectif n’est pas une visibilité parfaite. L’objectif est une confiance suffisante dans le fait que la reprise fonctionnera le moment venu. Pour les équipes IA, cette confiance est essentielle. Un entraînement prend des semaines. Des données ou des checkpoints perdus font reculer les projets. Votre système doit vous apporter la tranquillité d’esprit. Construisez une surveillance qui répond à ces questions : « Mes sauvegardes fonctionnent-elles ? Puis-je réellement restaurer ? » Tout le reste est secondaire. Commencez par les bases : surveillez l’achèvement des tâches, alertez en cas d’échec et testez la reprise chaque mois en vous appuyant sur une infrastructure de cible de sauvegarde. Élargissez ensuite en fonction des modes de défaillance rencontrés. Avec le temps, vous bâtirez des pratiques qui maintiennent votre infrastructure saine et digne de confiance. Les sauvegardes ne sont utiles que si vous savez qu’elles fonctionnent. La surveillance rend cette certitude concrète. Pour aller plus loin Qu’est-ce que le SIEM ? La gestion des informations et des événements de sécurité expliquée (en anglais) Piste d’audit du stockage (en anglais) Outils d’observabilité des données Comment survivre à une panne de data center (en anglais) Préserver l’intégrité des données face aux pannes de disques (en anglais) Sauvegarde et reprise Kubernetes en edge (en anglais) Résilience face aux pannes AWS (en anglais)
