Continuous Activity Monitoring

Overview

Detection is only useful if it’s continuous. Continuous Activity Monitoring means watching the backup environment in real time for suspicious behavior, rather than discovering problems during a scheduled review or an actual incident. This is achieved through Veeam ONE alarms and reports, Veeam Backup & Replication (VBR)’s built-in detection and access controls, Veeam Recovery Orchestrator (VRO)’s automated readiness verification, and the integration with third-party solutions - used together, not separately.

Why “Occasional” Monitoring Isn’t Enough

The gap between when something goes wrong and when it’s noticed is often the single biggest factor in how much damage an incident causes:

  • A ransomware attack can move from initial access to full encryption in a matter of hours; a weekly or monthly review cycle is far too slow to catch it in time to matter.
  • Configuration drift - an immutability setting quietly disabled, an alarm silently turned off, Four-Eyes Authorization disabled - is only caught by monitoring that’s actually running continuously, not by an occasional manual check.
  • Credential misuse (a compromised backup admin account being used at an unusual time, from an unusual location) is a fleeting signal; if nobody is watching in real time, the signal is gone by the time anyone looks.

Best Practices

Tune Alarms to Backup-Specific Risk Indicators

Generic infrastructure monitoring misses the signals that matter most for backup and recovery:

  • Enable and tune Veeam ONE’s predefined alarms built for this purpose - Immutability State, Possible Ransomware Activity (CPU, datastore write rate, and network transmit rate anomalies per VM), and Immutability Change Tracking - rather than relying only on generic job success/failure alerts.
  • Treat Veeam ONE’s Suspicious Incremental Backup Size alarm, unexpected retention policy changes, and a sudden drop in successful backups as high-priority signals, not routine noise.
  • Watch for timeshift detection warnings on Hardened Repositories: VBR blocks retention operations and raises a job-status warning when it detects clock manipulation - a classic way attackers try to defeat immutability - and this warning should be actively monitored, not just left on the job status screen.
  • Use the Threat Center in VBR to see flagged and at-risk workloads across the environment in one place, so signals from different sources roll up somewhere someone will actually look.
  • Regularly review which Veeam ONE alarms are actually enabled and tuned correctly; an alarm that exists on paper but isn’t firing provides a false sense of security.

Use Trip-Wires for Immediate, High-Confidence Alerts

Some of the most useful monitoring signals are the ones designed to have effectively zero false positives:

  • Place virtual trip-wires in Veeam ONE on sensitive, otherwise-unused accounts and resources, so any activity on them is treated as a near-certain compromise indicator rather than something that needs further investigation to confirm.
  • Extend the same trip-wire logic to honeypot servers and honeypot users - monitoring is what actually makes a honeypot useful; an unmonitored honeypot is just an unnecessary risk.
  • Give each trip-wire alarm a clear owner and escalation path, so a triggered alarm reliably reaches someone who can act on it quickly.
  • Forward the trip-wire event via Syslog (from Veeam ONE or directly from VBR’s Event Forwarding) to a SIEM, and let the SIEM’s own correlation rules raise the alert - useful when the security team already wants every signal, Veeam included, decided in one place.

Monitor Authentication and Privileged Actions Closely

Credential misuse is often the earliest visible sign that something is wrong:

  • Watch login activity for backup admin accounts specifically, given the elevated access they carry, and flag logins at unusual times, from unfamiliar locations, or on accounts that rarely authenticate.
  • Forward login and authorization events to a SIEM (via VBR’s own Event Forwarding or Veeam ONE’s Syslog integration) and let the SIEM’s correlation rules and alert profiles decide what counts as suspicious - a login threshold, an off-hours pattern, an unfamiliar location.
  • Veeam ONE alarms can also be forwarded directly into ServiceNow as incidents.
  • Correlate authentication activity with other signals (a login followed immediately by a configuration change, for example) using that same audit trail, rather than treating each data point in isolation.
  • Require a second approver for sensitive VBR operations - deletions, retention changes, disabling protection - with Four-Eyes Authorization. Every approval, rejection, and related setting change is logged under History > Authorization Events, giving a real-time audit trail for exactly this kind of scenario.
  • Weigh lockout against visibility for service accounts specifically: a strict lockout policy stops password-guessing, but locking a service account out can disrupt your own backup infrastructure. For those accounts, consider alarming on repeated failed attempts instead of locking them - trading containment for the visibility of watching the attempt happen.

Verify Recoverability Continuously, Not Just Backup Success

A successful backup job doesn’t guarantee a successful recovery, and that gap is only closed by monitoring both, continuously:

  • Enable VBR’s built-in Malware Detection so backups are screened for encryption activity and ransomware artifacts as they’re created, not only when someone happens to check.
  • Leave Veeam Recovery Orchestrator’s automated Readiness Check running on its default daily schedule for every enabled recovery plan.

Keep Monitoring Coverage Current

Monitoring that was correctly configured at deployment can silently fall behind as the environment evolves:

  • Confirm that new repositories, jobs, cloud targets, and newly protected workloads automatically fall under existing Veeam ONE alarm scope, and that new workloads are added to a VRO recovery plan, rather than assuming they are.
  • Periodically audit alarm and readiness-check coverage against the current state of the environment - hybrid and multi-cloud environments are the ones most likely to silently outgrow their original monitoring setup.

Common Pitfalls

  • Treating monitoring as something reviewed periodically (weekly, monthly) rather than something that runs, and is watched, continuously.
  • Leaving default or generic alarms in place without tuning them to backup-specific risk indicators like immutability state or unusual deletion patterns.
  • Setting up honeypots and trip-wires without actually monitoring them, which defeats their entire purpose.
  • Overlooking authentication and privileged-action activity as a monitoring signal, focusing only on job status.
  • Relying on manual DR testing instead of VRO’s automated daily readiness checks to confirm recoverability.
  • Assuming monitoring coverage automatically keeps up with a growing or changing environment without verification.

References

Back to top

Copyright © 2019 - 2026 Solutions Architects, Veeam Software.
Please note that information provided in this guide is not produced or verified by Veeam R&D but is a result of community effort based on the field observations.