Quantcast
Channel: Veeam Support Knowledge Base
Viewing all articles
Browse latest Browse all 4362

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)

$
0
0

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
Published: 2023-06-02
Last Modified: 2023-06-02

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.

Viewing all articles
Browse latest Browse all 4362

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>