#1 Global Leader in Data Resilience

Restore/Failover/SureBackup of Virtual Machines running Windows 8.1/Window Server 2012 R2 (or older) triggers chkdsk if Veeam Backup Server or Mount Server is Running Windows Server 2022 (or newer)

KB ID: 4445
Product: Veeam Backup & Replication | 11 | 12 | 12.1 | 12.2 | 12.3
Published: 2023-06-02
Last Modified: 2023-06-13
mailbox
Get weekly article updates
By subscribing, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.
This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply except as noted in our Privacy Policy.

Cheers for trusting us with the spot in your mailbox!

Now you’re less likely to miss what’s been brewing in our knowledge base with this weekly digest

error icon

Oops! Something went wrong.

Please, try again later.

Challenge

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:

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:

Cause

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.

Solution

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.

More Information

  • This issue affects all Virtual Machines (VMs) running Server 2012 R2/Windows 8.1 or older that were Powered On at time of backup/replication.
  • 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.
To submit feedback regarding this article, please click this link: Send Article Feedback
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.

Spelling error in text

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply except as noted in our Privacy Policy.
Thank you!

Thank you!

Your feedback has been received and will be reviewed.

Oops! Something went wrong.

Please, try again later.

You have selected too large block!

Please try select less.

KB Feedback/Suggestion

This form is only for KB Feedback/Suggestions, if you need help with the software open a support case

By submitting, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.
This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply except as noted in our Privacy Policy.
Verify your email to continue your product download
We've sent a verification code to:
  • Incorrect verification code. Please try again.
An email with a verification code was just sent to
Didn't receive the code? Click to resend in sec
Didn't receive the code? Click to resend
Thank you!

Thank you!

Your feedback has been received and will be reviewed.

error icon

Oops! Something went wrong.

Please, try again later.