Skip to main content

Troubleshoot backup and restore issues with Hyper-V virtual machines

This topic describes common workarounds of issues that you might encounter while backing up or restoring Hyper-V virtual machines.

1. Linux virtual machine boots into maintenance mode after restore

Issue

If the disk sequence changes after restore, the boot order changes for the Linux virtual machine and the virtual machine boots into maintenance mode or some virtual disks are not visible.

Resolution

For the Linux virtual machine, change the disk sequence in /etc/fstab. The virtual machine boots without any problem after you enter the correct disk sequence. For more information, see RedHat documentation. [External link]

2. Virtual machine restored to an alternate host fails to start

Issue

When VM is restored on another host, sometimes it fails to start with an error: ' Unnamed VM' could not initialize. (Virtual machine ID).
The event log shows the error: The security ID structure is invalid (0x80070539).

Resolution

On the Hyper-V host:

  1. Open an administrative PowerShell command window.

  2. Run:

    Grant-VMConnectAccess -VMName "Name of VM that is not starting" -UserName "Domain and username of the current user"

For more information, see Virtual machine cannot start - The security ID structure is invalid (0x80070539)[External link to a Microsoft support article.]

3. Cannot perform a file-level restore from a virtual machine backup

Issue

One of the reasons why a virtual machine FLR fails is the presence of user recovery points. If user recovery points are present, Druva backs up a virtual machine, however, FLR from such virtual machine backups is currently not supported. The backup job for such a virtual machine is marked as successful with errors.

Resolution

Delete the user recovery points and backup the virtual machine to use file-level restore.

4. Error messages are encountered at the time of virtual machine restore

Issue
The following error messages are encountered at the time of virtual machine restore:

  • Failed to add VHDs to VM dev03 (#10009000b)

  • General access denied

This error can occur if you are restoring a virtual machine or a virtual disk to a Windows Server 2008 or Windows Server 2008 R2 host with SMB share target, and appropriate write issues on the share are not available.

Resolution

To resolve this issue:

  • Flush and purge the existing authentication tickets between the host and the share, and

  • Re-apply write permissions to the target folder

For example:

  • Hyper-V host is Domain\hypervhost1

  • SMB Share system is Domain\smbsharesystem

To flush and purge the existing authentication tickets:

Run the following commands as administrator on the Hyper-V host:

klist tickets 
klist purge

Create a new folder and apply write permissions to the target folder

Run the following commands as administrator on the Hyper-V host

MD C:\SomeFolder 
ICACLS C:\SomeFolder /GRANT Domain\Administrator:(OI)(CI)F /GRANT Domain\hypervhost1$:(OI)(CI)F Domain\smbsharesystem$:(OI)(CI)F 
NET SHARE SomeFolder=C:\SomeFolder /GRANT:Domain\Administrator,FULL /GRANT:Domain\hypervhost1$,FULL /GRANT:Domain\smbsharesystem$,FULL

šŸ“ Note
ā€‹Use the above example as a guide. Replace the inputs SomeFolder, hypervhost1, and smbsharesystem based on your setup.

5. Restore to an alternate path is successful but additional disk drives are missing, failed, or offline.

Issue

This issue can occur when you are restoring virtual machines to Windows 2008 server, and you have multiple virtual disks of different types attached to it, such as simple, spanned, striped, or mirror disk.

In such a case, after you restore the virtual machine and turn it on, you can only see the primary disks in the virtual machine.

Resolution

Launch the DISKPART utility or the disk management console ( diskmgmt.msc ), select each disk individually, and bring each virtual disk online manually. For example, run the following commands in the DISKPART utility:

DISKPART> select disk 1 
Disk 1 is now the selected disk. 
DISKPART> DISKPART> ONLINE DISK 
DiskPart successfully onlined the selected disk.

6. Backup fails with the HYPERV10 error after re-registering a Hyper-V host

Issue

This issue can occur when you generate a re-registration activation token for one host and use the token to re-register another host. For example, you have two hosts registered with Druva for backup, hosts h1 and h2. Host h1 has virtual machines a1, a2, and a3 running on it, and host h2 has virtual machines b1 and b2 running on it.

If you generate a re-registration token for the host h2, but install and activate the agent using the re-registration token on host h1:

  • Backup jobs for virtual machines b1 and b2 fail since the host h2 is still disconnected

  • Backup jobs for virtual machines a1, a2, and a3 fail since the host h1 is activated, however, the agent is looking for virtual machines b1 and b2 on the host

  • Host h1 is listed as host h2 on the Hyper-V page of the Management Console in the organization it was registered

  • There are two hosts listed as host h2 on the Hyper-V page of the Management Console in the organization the two hosts were registered

Resolution

In this example, there are two hosts that are listed as h2, however, the host that is still connected to the Druva Cloud is host h1. To resolve this issue, re-register the host h1 that is listed as host h2 with a new re-registration token. After you re-register the host, you can see that the host h1 is now listed correctly on the Management Console. After you re-register the host h1, select the disconnected host h2 and re-register it with a new re-registration token. After you re-register the host h2 with the correct activation token:

  • Both the hosts are connected to the Druva Cloud

  • Both the hosts are listed properly with the backup jobs running as expected

7. Failed to create application-consistent backup recovery points on Hyper-V host Windows Server 2019 with the guest operating server Windows Server 2012

Issue
The creation of the production checkpoint on Hyper-V Guest OS Windows Server 2012 fails for the older version of Integration Services. For older version of Integration Services, the Progress logs shows the following details:

Failed to take app consistent checkpoint. Trying crash consistent checkpoint

Resolution

To ensure that your backups are application-consistent, download and install updates on the Windows update page of the Hyper-V host.

8. Why do Hyper-V VMs remain in the 'Backing up' state even when backups are not running?

Issue

This is typically caused by lingering VSS snapshots or Hyper-V recovery checkpoints, often left behind by another backup application.

Resolution

  1. Check for and remove any lingering third-party VSS snapshots (vssadmin).

    Get-WmiObject Win32_ShadowCopy | Select-Object ID, VolumeName, InstallDate

    Alternatively, use the VSS admin tool:

    vssadmin list shadows
    ā€‹

    šŸ“ Note

    ā€‹If rogue snapshots from third-party tools are identified, clear them using the vssadmin delete shadows command.

  2. Delete any stuck (lingering) Hyper-V Recovery Checkpoints.

  3. Restart the Volume Shadow Copy (VSS) and Hyper-V Virtual Machine Management (VMMS) services.

Best Practice: Stagger backup schedules between Druva and other backup applications to prevent simultaneous access to the Hyper-V VSS Writer, which can cause VMs to remain in the 'Backing up' state.

9. Resolving Hyper-V Resilient Change Tracking (RCT) failures during incremental backups

Issue

Incremental backup jobs may fail or automatically fall back to full backups when Hyper-V Resilient Change Tracking (RCT) files (.mrt or .rct) become corrupted or go out of sync. This commonly occurs after an unexpected host shutdown or VM migration.

Resolution

  1. Disable backup for the affected VM in the Druva Management Console.

  2. Shut down the target VM on the Hyper-V host, if permitted.

  3. Reset RCT tracking by running the following PowerShell commands on the Hyper-V host:

    $vm = Get-VM -Name "VM_NAME" $vm | Set-VM -ConfigurationLocation $vm.ConfigurationLocation

  4. If the issue persists, delete the corresponding .rct and .mrt files from the VM's virtual hard disk directory while the VM is powered off.

  5. Power on the VM and initiate an ad-hoc backup from the Druva Management Console.

šŸ“ Note

ā€‹Deleting RCT files causes Druva to perform a one-time full scan (synthetic full backup) to re-establish the change-tracking baseline. After that, incremental backups should resume normally.

10. Resolving 'Hyper-V VSS Writer in Failed state' error during backup jobs

Issue

Hyper-V backups can fail with VSS-related errors when the Microsoft Hyper-V VSS Writer on the host enters a Failed or Timed out state.

Resolution

  1. Open PowerShell or Command Prompt as an administrator on the Hyper-V host.

  2. Check the status of the VSS writers:
    ā€‹vssadmin list writers

  3. Locate Microsoft Hyper-V VSS Writer and verify whether its state is [11] Failed or [5] Waiting for completion.

  4. Restart the Hyper-V Virtual Machine Management service to reset the writer without rebooting the host:

    Restart-Service vmms

  5. Run vssadmin list writers again and confirm that the writer state has returned to [1] Stable.

šŸ“ Note

ā€‹If the writer frequently enters a failed state, verify that Hyper-V Integration Services on the guest VMs are up-to-date and no host-level antivirus scans are locking the VM disk files such as .vhdx.

Related Articles
Did this answer your question?