Virtualisation
Supervision Hyper-V et Veeam, du point de contrôle oublié à la sauvegarde sabotée
Un point de contrôle pris avant une mise à jour il y a quatre mois, un volume du cluster rempli à 88 %, une VM créée au printemps que personne n'a ajoutée aux sauvegardes : rien de tout cela ne déclenche d'alerte, jusqu'au jour où il faut restaurer. FirstSI relève l'état de vos hôtes Hyper-V, de votre cluster et de vos sauvegardes Veeam, en lecture seule, et vous le dit avant.
Démo en accès libre, sans inscription : 138 machines fictives, les treize modules.
POINT DE CONTRÔLE serveur de l'ERP : pris il y a 118 jours, disque +240 Go
CLUSTER volume partagé principal à 88 %, plein dans 26 jours
SAUVEGARDE deux VM dans aucun travail de sauvegarde
BASCULE si un hôte s'arrête, toutes les VM repartent sur les autres
VEEAM travaux de la nuit : 11 réussis, 1 en avertissement
Ce que vous voyez enfin
Les points de contrôle oubliés
Chaque point de contrôle ressort avec son âge et la taille de son disque. Celui pris « juste avant la mise à jour » ne grossit plus en silence pendant des mois.
Les disques qui dérivent
Disques différentiels qui enflent, chaînes de disques cassées, disque parent introuvable : ce qui empêcherait une VM de redémarrer est signalé avant le prochain arrêt.
La perte d'un nœud, calculée
Mémoire et processeurs restants si un hôte s'arrête : vous savez à l'avance si toutes les VM repartiraient sur les autres, ou lesquelles resteraient éteintes.
Les volumes partagés qui se remplissent
La croissance des volumes du cluster est suivie, avec la date de saturation prévue. Vous commandez des disques en avril, pas le soir où tout s'arrête.
Chaque VM, protégée ou non
Les VM qui ne figurent dans aucun travail, les sauvegardes en échec, les anciens travaux restés actifs, les points de restauration laissés en place : la couverture réelle, VM par VM.
Le sabotage des sauvegardes
Travail supprimé, planification coupée, dépôt disparu, points de restauration qui chutent, VM supprimées ou arrêtées en masse : ce que fait un rançongiciel avant de chiffrer déclenche une alerte, rapprochée des ouvertures de session administrateur.
Dimanche, 2 h 14
La planification coupée en pleine nuit
Un dimanche à 2 h 14, la planification du travail qui sauvegarde les bases de données est désactivée. Personne n'est d'astreinte sur les sauvegardes, et lundi matin tout semblerait normal : aucune sauvegarde n'a échoué, puisqu'aucune n'a été lancée.
FirstSI compare chaque relevé au précédent. Il voit la planification coupée, puis, dix minutes plus tard, les points de restauration d'un autre travail qui fondent. Il rapproche les deux d'une ouverture de session administrateur sur le serveur de sauvegarde, à 2 h 06, avec un compte qui ne s'y connecte jamais.
L'incident critique part par e-mail et par webhook vers l'astreinte. Le compte est désactivé à 2 h 31, la planification rétablie, et les sauvegardes de la semaine sont intactes. Rien n'a été chiffré.
02:06 SESSION ouverture de session administrateur sur le serveur de sauvegarde
02:14 SABOTAGE planification coupée, travail des bases de données
02:24 SABOTAGE points de restauration en chute sur un autre travail
02:31 COMPTE compte désactivé, planification rétablie
Comment ça marche
L'agent sur les hôtes
Le même agent FirstSI s'installe sur les hôtes Hyper-V et sur le serveur de sauvegarde. Il reconnaît seul ce que la machine porte.
Un relevé discret
Quelques secondes de relevé tous les quarts d'heure, en lecture seule : rien n'est jamais modifié sur les hyperviseurs, le cluster ni les sauvegardes.
Les alertes et l'enquête
Les constats deviennent des incidents, et l'assistant IA comme le pré-diagnostic des tickets s'en servent : « le serveur est lent » arrive avec l'état de son hôte.
Questions fréquentes
FirstSI modifie-t-il quelque chose sur mes hyperviseurs ?
Non. L'agent lit l'état des hôtes, du cluster et des sauvegardes, sans jamais rien changer : aucun point de contrôle supprimé, aucune VM déplacée, aucun travail modifié.
Faut-il un agent sur chaque hôte du cluster ?
Oui, sur chaque hôte Hyper-V, et un sur le serveur de sauvegarde. C'est le même agent que pour les autres modules : sur des serveurs déjà équipés, il suffit d'activer la virtualisation depuis la console.
Quels environnements sont pris en charge ?
Les hôtes Hyper-V, seuls ou en cluster de basculement, et les sauvegardes Veeam Backup & Replication.
Comment FirstSI repère-t-il un sabotage des sauvegardes ?
Il compare chaque relevé au précédent : un travail qui disparaît, une planification coupée, un dépôt absent, des points de restauration qui chutent, des VM supprimées ou arrêtées en nombre. Si cela suit une ouverture de session administrateur, l'incident passe en critique.
Puis-je savoir quelles VM ne sont pas sauvegardées ?
Oui. FirstSI croise la liste des VM de vos hôtes avec les travaux de sauvegarde et désigne celles qui n'y figurent pas, ainsi que celles dont la dernière sauvegarde a échoué.
D'autres questions sur l'installation, l'hébergement, le RGPD ou les intégrations ? Toutes les questions fréquentes
Pour aller plus loin
Les mêmes données servent plusieurs besoins. Ces pages en montrent d'autres facettes.
Sécurité des serveurs
Persistance, état de sécurité, capacité.
En savoir plus SIEMSIEM et détection d'incidents
Des incidents corrélés, avec leur chronologie.
En savoir plus Bases de donnéesBases de données
Performances, tâches de fond, sauvegardes.
En savoir plusDans la documentation
Sachez si vos VM repartiraient, avant d'en avoir besoin
Une démonstration commentée vous montre les points de contrôle, la capacité du cluster et la couverture des sauvegardes, VM par VM.