Loading...
Loading...
In the following scenarios, a Virtual Machine[1] that was running Server 2012 R2/Windows 8.1 or lower will perform chkdsk on the first boot if the Veeam Backup Server is running Server 2022: A non-Domain Controller VM is being tested by SureBackup with the "Automatically disable Windows Firewall" option enabled. Any Domain Controller VM being tested with SureBackup using the "Domain Controller (Authoritative Restore)" role. A Replica Failover where Re-IP was enabled in the Replication Job. Any restore to Microsoft Azure. In the following scenario, a Virtual Machine[1] that was running Server 2012 R2/Windows 8.1 or lower will perform chkdsk on the first boot if the Mount Server assigned to the Backup Repository, where the backup files are stored, is running Server 2022: Any restore where Secure Restore is enabled.
In the scenarios mentioned above, the disks of VMs are mounted to the indicated infrastructure component (Veeam Backup Server or Mount Server). When the specified infrastructure component is running Server 2022 or higher, it detects the guest disks from those older operating systems (Server 2012 R2/Windows 8.1 or older) as corrupted. As part of that erroneous disk corruption detection, the OS of the infrastructure component marks the guest OS's disks as needing to run a check disk on the next boot.
This issue's only impact on operations is the delay caused by the chkdsk process, which impacts the initial OS boot speed. Restores For restore operations where this issue occurs when Secure Restore is used, the issue can be mitigated by either: assigning a server that uses Server 2019 or older as the Mount Server within the settings of Repository where the backups are stored. or not enabling Secure Restore when restoring VMs that were running Server 2012 R2/Windows 8.1 or older. For Restore to Microsoft Azure, the only way to mitigate this issue is to migrate the entire Veeam Backup & Replication deployment to a machine running Server 2019 or older. Replica Failover Because this issue relates to the OS of the Veeam Backup Server itself running Server 2022 or higher, the only way to eliminate the initial chkdisk after failover of replicas running Server 2012 R2 or older is to migrate the Veeam Backup & Replication deployment to different machine running Server 2019 or lower. It may be advisable to tolerate the initial boot delays instead and plan to upgrade the older VMs to a newer operating system, as Server 2012 R2 will reach end-of-life on October 10, 2023. SureBackup For SureBackup jobs, this issue will most often cause VMs running those older OSs to fail to pass SureBackup testing with the error: OS did not boot in the allotted time This is because the chkdsk delays the initial boot causing it to not complete within the Maximum allowed boot time. For Domain Controllers with the Domain Controller (Authoritative Restore) role selected, there is no way to prevent the check disk from occurring. This role is necessary to ensure that the Domain Controller is started in an authoritative state and, therefore, cannot be disabled to work around this issue. Instead, the Maximum allowed boot time must be increased.The time required to complete the chkdsk operation will depend on the disk size and the underlying backup storage. The best advice we can provide is to try increasing the Maximum allowed boot time by 900 seconds for the Domain Controller until the error stops occurring (1800, 2700, 3600, etc.). For VMs other than those assigned the Domain Controller (Authoritative Restore) role, disable the Automatically disable Windows Firewall option instead.
This issue affects all Virtual Machines (VMs) running Server 2012 R2/Windows 8.1 or older that were Powered On at the time of backup/replication. The issue explained in the Cause section can also happen during a Guest Files Restore. However, it does not affect the Guest Files Restore because it does not require booting from the disk designated by the Mount Server's OS. Still, if someone reviews the event logs on the Mount Server running Server 2022, they will see an NTFS error with EventID: 55. For VMware VMs, the issue will occur whether Application-Aware Processing was enabled or not. For Hyper-V VMs running those older OSs, the issue will only occur when Application-Aware Processing is not enabled.
Veeam Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.