SureBackup Boots some VMs CHKDSK; IR not booting into CHKDSK

[ideenj]

I am currently working on one of our Veeam setups with SureBackup and am wondering if anyone else has seen this behavior before I open up a case.

Veeam/SureBackup Config:
- Veeam B&R 12.1.1.56
- Single Virtual Lab setup with Advanced multi-host (just redeployed Virtual lab upon updating Veeam)
- Only have 1 Isolated network mapped (on same network as the Veeam B&R Server)
- There are multiple VLANs in the environment; as we not running ping tests, we only have the 1 Isolated network configured on the virtual lab. This lives on the same 'general server' network with the Veeam B&R server.
- We only want to run Heartbeat tests on the VMs at this time.
- We are not redirecting the write-cache at this time.

VMware 7.0.3, 22348816
- There are multiple VMware clusters, all ESXi hosts are running on the same VMware version

This setup is running a physical server doubling as a Proxy/Repo that has plenty of resources.

Upon running any SureBackup job - it seems a large number of VMs are booting into CHKDSK - we have a timeout set to 1800 sec that can accommodate most VMs, but will fail on the really large machines. Some of the machines we are testing are running on the same cluster where the virtual lab is located and they are booting into CHKDSK as well.

I tested to see if we got the same behavior running Instant Recovery (network card disconnected) with 2 problem VMs and the VMs are booting directly into Windows. We are not redirecting the write cache as we tried to mimic as much of the SureBackup configuration as possible.
- Issue appears to be isolated to Windows VMs only and we have a mix of Windows versions in the environment; OS version seems irrelevant.

Any suggestions on what might be causing the VMs to boot into CHKDSK?

[PetrM]

Hi Ideen,

Have you already tested Instant Recovery and SureBackup from the same full restore point? If yes, it would be best to open a support case and work on this technical issue. Also, for testing purposes, it's worth trying to recover from the full backup created in Network mode for testing purposes.

Please don't forget to share a support case ID with us.

Thanks!

[ideenj]

Case #07127567

[ideenj]

This has been resolved.

The underlying issue ended up being that some of the VM's (mix of OS's ranging from 2008R2, 2012, 2016, 2019, and 2022) did not like having the "Automatically disable Windows Firewall" selected and it was triggering a CHKDSK. Support and I unchecked this box and everything started working as expected.