Virtualisation
Hyper-V and Veeam monitoring, from the forgotten checkpoint to the sabotaged backup
A checkpoint taken before an update four months ago, a cluster volume at 88%, a VM created in the spring that nobody added to the backups: none of it raises an alert, until the day you need to restore. FirstSI reads the state of your Hyper-V hosts, your cluster and your Veeam backups, read-only, and tells you first.
Open-access demo, no sign-up: 138 fictional machines and all thirteen modules.
CHECKPOINT ERP server: taken 118 days ago, disk +240 GB
CLUSTER main shared volume at 88%, full in 26 days
BACKUP two VMs in no backup job
FAILOVER if a host stops, every VM restarts on the others
VEEAM overnight jobs: 11 succeeded, 1 with a warning
What you finally see
Forgotten checkpoints
Every checkpoint shows up with its age and the size of its disk. The one taken “just before the update” no longer grows quietly for months.
Disks that drift
Swelling differencing disks, broken disk chains, a missing parent disk: anything that would stop a VM from restarting is flagged before the next shutdown.
Losing a node, worked out
Memory and processors left if a host stops: you know in advance whether every VM would restart on the others, or which ones would stay off.
Shared volumes filling up
Cluster volume growth is tracked, with the date each volume is expected to be full. You order disks in April, not on the evening everything stops.
Every VM, protected or not
VMs in no job, failed backups, old jobs still active, restore points left behind: your real coverage, VM by VM.
Backup sabotage
A deleted job, a disabled schedule, a vanished repository, restore points dropping, VMs deleted or shut down en masse: what ransomware does before it encrypts raises an alert, matched against administrator logons.
Sunday, 2:14 am
The schedule switched off in the middle of the night
One Sunday at 2:14 am, the schedule of the job that backs up the databases is disabled. Nobody is on call for backups, and on Monday morning everything would look normal: no backup failed, because none was started.
FirstSI compares each reading with the previous one. It sees the disabled schedule, then, ten minutes later, the restore points of another job melting away. It links both to an administrator logon on the backup server at 2:06 am, with an account that never signs in there.
The critical incident goes out by email and webhook to the on-call team. The account is disabled at 2:31 am, the schedule restored, and the week's backups are intact. Nothing was encrypted.
02:06 LOGON administrator logon on the backup server
02:14 SABOTAGE schedule disabled, databases job
02:24 SABOTAGE restore points dropping on another job
02:31 ACCOUNT account disabled, schedule restored
How it works
The agent on the hosts
The same FirstSI agent installs on the Hyper-V hosts and on the backup server. It works out for itself what the machine runs.
A discreet reading
A few seconds of collection every quarter of an hour, read-only: nothing is ever changed on the hypervisors, the cluster or the backups.
Alerts and investigation
Findings become incidents, and both the AI assistant and ticket pre-diagnostics draw on them: “the server is slow” arrives with the state of its host.
Frequently asked questions
Does FirstSI change anything on my hypervisors?
No. The agent reads the state of the hosts, the cluster and the backups without ever changing anything: no checkpoint deleted, no VM moved, no job modified.
Do I need an agent on every host in the cluster?
Yes, on every Hyper-V host, plus one on the backup server. It is the same agent as for the other modules: on servers that already have it, you simply switch on virtualisation from the console.
Which environments are supported?
Hyper-V hosts, standalone or in a failover cluster, and Veeam Backup & Replication backups.
How does FirstSI spot backup sabotage?
It compares each reading with the previous one: a job that disappears, a disabled schedule, a missing repository, restore points dropping, VMs deleted or shut down in numbers. If this follows an administrator logon, the incident is raised to critical.
Can I find out which VMs are not backed up?
Yes. FirstSI matches the VMs on your hosts against the backup jobs and names the ones that are missing, along with those whose last backup failed.
More questions about installation, hosting, GDPR or integrations? All frequently asked questions
Take it further
The same data serves more than one purpose. These pages show it from other angles.
Server security
Persistence, security status, capacity.
Learn more SIEMSIEM and incident detection
Correlated incidents, with their timeline.
Learn more DatabasesDatabases
Performance, background jobs, backups.
Learn moreIn the documentation
Know whether your VMs would restart, before you need them to
A guided demo shows you checkpoints, cluster capacity and backup coverage, VM by VM.