Skip to main content

I’m using B&R 12.1.1 and having the following error with a single Server 2016 VM backup.

Failed to index guest file system. VSSControl: Index failed

I’ve checked that all discs have plenty space but not sure where to look for more information.

Any suggestions welcomed.
 

I’d suggest to head to the guest system and analyze the logs generated in %programdata%\Veeam\Backup

Especially look for files with the base name “VeeamGuestIndexer”.

Find more info here: KB1789: How to Locate and Collect VSS/VIX Log Files From Guest OS (veeam.com)


I’d say the easiest place to start would be the status of the VSS Writers.

VSSAdmin list writers

 

Check all the writers are ok. Typically if some are failed a service restart or server reboot will help.

Otherwise I’d check the job log files in “%programdata%\veeam”


I’d say the easiest place to start would be the status of the VSS Writers.

VSSAdmin list writers

 

Check all the writers are ok. Typically if some are failed a service restart or server reboot will help.

Otherwise I’d check the job log files in “%programdata%\veeam”

 

I’d suggest to head to the guest system and analyze the logs generated in %programdata%\Veeam\Backup

Especially look for files with the base name “VeeamGuestIndexer”.

Find more info here: KB1789: How to Locate and Collect VSS/VIX Log Files From Guest OS (veeam.com)

Thank you both for the responses.  Sorry, been off for a couple of days so haven’t responded.

Status of VSS Writers appears to be fine.  They all have a ‘Stable’ state and ‘No error’

 

After comparing the VeeamGuestIndexer log in the above directory on the affected system and another system that’s working, I can see the point where it fails.

On a working system I see the following.

07/03/2024 22:06:09   3688              Execute FindFirst/FindNext algorithm!
07/03/2024 22:06:09   3688              +++++++++++++++++++++++++++++++++++++++++++++++++++++
07/03/2024 22:06:21   3688              Combining tables into one file: 6C:\Windows\VeeamVssSupport\IndexData\volume.e_.ifd].
07/03/2024 22:06:22   3688              Combining tables complete!

The log file then continues and shows the indexing operation completing.

However, on the system with the indexing problems, I see this

07/03/2024 22:03:33   6220              Execute FindFirst/FindNext algorithm!
07/03/2024 22:03:33   6220              +++++++++++++++++++++++++++++++++++++++++++++++++++++
07/03/2024 22:15:15   6220  INFO        Writing dump. Dump path: C:\ProgramData\Veeam\Backup\Indexer_crash_10.mdmp.

The indexing log ends at this point.

Appreciate any suggestions.


I assume this is a VM level backup rather than agent?

Do you have gust file indexing and Application Aware processing enabled? If so i’m wondering do you get the same issue with those disabled?


Guest file indexing has been enabled.  App-aware processing is NOT enabled.

This is a VM backup of multiple VM’s.  Error has only started since enabling Guest Indexing (for malware detection) after upgrading to V12.  But the strange thing is it only affects this single VM - all other VM’s, including the one I compared it to, are carrying out the indexing successfully.  So definitely appears to be something specific to this VM.  It’s a Win Server 2016 (as was the one I compared it to)


Are you able to take VSS snapshots manually on the VM in question?

This KB article should assist in that. KB1980: Using the Diskshadow Utility to Manually Test VSS Operations (veeam.com)

Failing that I’d recommend logging a ticket with support to investigate further.

 


Are you able to take VSS snapshots manually on the VM in question?

This KB article should assist in that. KB1980: Using the Diskshadow Utility to Manually Test VSS Operations (veeam.com)

Failing that I’d recommend logging a ticket with support to investigate further.

 

Thanks for your help Mark, I’ll give that a try now.  👍


Check the permissions as well. App aware and indexing require elevated permissions.

Use the other VM’s for reference. It will be 1 account for the entire job. 

 

If that is right a reboot, or active full of that machine could be worth a try.

 

As a troubleshooting technique, create a new job, with just the single VM and see if it works. 

 


Comment