Skip to main content

When auditors come knocking—or worse, when bad actors strike—not having accurate and complete event logs can make all the difference in how your organization survives the encounter.

However, users are often understandably more focused on day-to-day operations and only think to look for this information once it’s needed (and when time is of the essence).

The good news is that all the information you need—including where to find changes in Veeam server user access permissions, failed login attempts, and failed RDP connections—is available in several different locations, including:

  • Windows Event Viewer
  • Veeam Backup and Replication Audit logs for performed restores
  • Veeam One Audit log
  • The individual application log(s)

 

Windows Event Viewer

Many Veeam activities (success, warning, and failures) get logged to the Windows Event viewer by default.

 

To see these events from within the Veeam Backup and Replication (VBR) server, open the Windows Event Viewer console and Migrate to the Veeam Backup node.  For a Windows Server running the Veeam Agent for Windows, investigate the Veeam Agent node.

 

 

Some captured events include:

  • Changes to the VBR security groups
  • Changes to repository settings
  • Changes to the general options in the VBR GUI
  • Passwords in the password manager change

 

A complete list can be found in the Veeam Backup and Replication User Guide.

https://helpcenter.veeam.com/docs/backup/vsphere/vbr_event_general.html?ver=110

 

 

Windows can capture the state of login attempts to the server and other applications to the Event Viewer logs if this feature is enabled through a group policy.  It is off by default.

 

These Veeam events can be alerted by any other software that can monitor and exam Windows Events Logs Like Microsoft System Center.

 

Veeam Backup and Replication Audit log location

 

Restore operations performed in Veeam Backup and Replication (VBR) server console get logged to an audit file stored on the Server.  By default, the path to the audit logs is %ProgramData%\Veeam\Backup\Audit. 

 

This location can be changed on the general options page in the VBR GUI.

 

Just drill down through the log location to find the restore files needed to get to the logs.  In my case, I am looking for a SQL Explorer restore performed in August 2022.  Since the restore was done in the latest month, I’ll look in the file with the same month digit as the restore I want to check. Open the file and check the date range of the file.

I found the SQL restore I am looking for.  When I opened it up, I saw that a SQL restore was performed on 8/8 at 18:46 by a user.

 

 

Veeam One

 

Veeam One is a backup and report server that can collect and hold events from one to multiple VBR servers in a DB.

 

Two reports in Veeam One show information about a customer’s Veeam backup environment.

  • Backup Infrastructure Audit
  • Backup Objects Change Tracking

Both reports can be scoped to a specific time frame, objects, and jobs. 

The record all changes made to the Veeam configuration database along with date change, who changed something, and what was changed.

 

The reports can be found in the Veeam One Report interface under the Backup Monitoring section.

 

Veeam Backup and Replication logging

 

VBR provides detailed logging of almost all backup and restore-related events. These logs can be accessed from the following locations.

  • On the backup server, log files are stored in the following folder: %ProgramData%\Veeam\Backup.
  • If you run Veeam Backup & Replication Console as a non-privileged user, log files are stored in the user’s AppData folder: \<username>\AppData\Local\Veeam\Backup.
  • On Linux servers and ESXi hosts, logs are stored in the following directory: /var/log/VeeamBackup/ or /tmp/VeeamBackup
  • On Microsoft Windows servers, logs are stored in the following directory: %ProgramData%\Veeam\Backup

Providing accurate logs that are easy to view is essential to monitoring the health of a server and the backup environment.  Logging also helps notice and detect any drift away from a proper and secure system, either accidentally or by a rogue insider.

Thanks for sharing, I usually set my logs a bit larger on my servers these days for some extra retention too. 


Thank you for the sharing and great explanations @vmJoe 


What I’m missing in event is information about deleted backups, modified retention times (→ shorter or zero), change of backup jobs, general high number of changes in backup environment. 

 

I’ve the fun task to deliver data to SIEM team but I just can’t get what they need.

 

 

+1 maybe open a feature request on r&d forum? What do you think @Mildur ?

It’s not acceptable for us (from my company) to send a pdf report to Security Team. They already have a lots of data to process in siem, that's enough.


Great article! saved on my bookmarks! 👍


What I’m missing in event is information about deleted backups, modified retention times (→ shorter or zero), change of backup jobs, general high number of changes in backup environment. 

 

I’ve the fun task to deliver data to SIEM team but I just can’t get what they need.

 

 

If you have Veeam One you can look at the Audit report.  That should most of what you are looking for.


What I’m missing in event is information about deleted backups, modified retention times (→ shorter or zero), change of backup jobs, general high number of changes in backup environment. 

 

I’ve the fun task to deliver data to SIEM team but I just can’t get what they need.

 

 


The SNMP mibs are based on job monitoring - red, yellow, green and runtime stats. It’s really basic monitoring.  Most all Veeam events -security, config changes, restores, job runs, etc. get sent to the event logs.  This function was actually added to VBR to make it easier to get VBR info into Windows System Center Operations Monitor (SCOM) which allowed for more granular reporting and Alerts from or SCOM Management Pack - aka The MP! The MP is our Enterprise monitoring and alerting program. 

 


 

 


Great post @vmJoe , thank you!
 

@dloseke , snmp settings on vbr console is for monitoring purpose, the configuration should be the same as define in snmp agent on your windows host to works properly. It won’t be useful for logs monitoring but it could be for jobs if you need.

It will depend what is your observability/logs infra behind but you could use nx logs to send veeam logs. Disclaimer, veeam logs could be verbose 🙂.

https://nxlog.co/products/nxlog-community-edition

If you are running elastic, check link below:

https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-installation-configuration.html
https://www.elastic.co/guide/en/beats/winlogbeat/8.3/winlogbeat-installation-configuration.html


Such a great piece! Thank you @vmJoe 


Veeam does not have a native way to push syslog to other applications without use of a few API calls, and/or robo copy.  However, there are plenty of tools that can read read the Windows Event Logs.  Veeam started putting VBR events in the Event Viewer as a way to get them into Microsoft System Center Operations Monitor (SCOM) so we could alert on them with the MP.   There are plenty of tools that can report and alarm off of Windows Events. 

 

In certain cases, Veeam One custom alarms can be triggered from a specific event log message as well.

 

VBR can send basic SMNP traps to an SMNP trap receiver.  The MIB is in the Installation iSO.  


I’m not sure I ever really looked, and I’m not sure that I’d want them in there, but is there a capability to push the logs to a Syslog server so that they can feed into our SIEM solution?  I guess I do see in VBR some general settings for SNMP, but I’ve never played with those at all.

 

 


Yeah I love that some logs are in the Windows Event Viewer which helps when troubleshooting.  Great share and post!


Comment