Host-based VM Backup Related

Unable to take a quiesce snapshot of Windows Server 2019 VM during backup.
Symptom
When backing up Windows 2019 VM, you may see an error message in backup job activity log as given below.
Could not take snapshot of the virtual machine. ESX Server/vCenter Server reported the following error: An error occurred while quiescing the virtual machine. See the virtual machine's event log for details.
Note: If the option Take snapshot without quiescing the guest if creating a quiesced snapshot fails is selected in the backup plan, the backup job ignores the error and continues taking a snapshot without quiescing the VM. However, in this case of a crash consistent backup the backed up data integrity is not guaranteed.
Solution
This issue is related to VMware. The issue has no workaround. For reference, view VMware KB link.
The option workingDir is lost after VM is restored and VMDK is still restored to the location specified by workingDir.
Symptom
If a VM is configured with a different workingDir other than default one (the same location of VM), after VM recovery the configued workingDir is lost but VMDK of VM is still restored to the location specified by original workingDir. This issue happens only when:

The option, Restore to original location is used.
Before backup, user manually creates snapshot in the VM.

Solution
The option workingDir is lost after VM recovery:
Arcserve UDP does not back up VMs configuration file (.vmx file) directly, instead fetches VMs configuration information through vSphere API. However, as workingDir option is not fetched by vSphere API, Arcserve UDP cannot back up information about workingDir configuration information. When necessary, manually set workingDir option after VM is restored.
VMDK is restored to the location specified by workingDir
After user manually creates a snapshot, a delta VMDK is created in the location of workingDir. The delta VMDK becomes the active disk of this VMDK. Thus, when Arcserve UDP backs up the VM, the location of workingDir is recorded in recovery point as part of VMDKs information. As a result, when restoring the VM, by default Arcserve UDP restores to this location (workingDir). As a workaround, use UDPs option of Restore to alternative location and manually specify the location where VMDK is restored.
Agentless backup of vSphere VM backs up corrupt data when VM runs on SEsparse snapshot.
Symptom

During agentless back up of a VM that has manually created snapshot, the backed up data may be corrupted if virtual disk of VM:

Resides in VMFS-5 datastore or NFS datastores and the size is 2 TB or more
Resides in VMFS-6 datastores

Such a condition may result into the following problems in UDP:

Catalog job fails
Check recovery point fails
Assured Recovery job fails
Restored VM fails to boot

Solution
This known issue of vSphere is fixed in vSphere 6.7 U1. For workaround on other vSphere versions, refer to the VMware KB article.
Unable to mount the backup session.
Symptom
The backup session is not mounted.
Solution
The issue occurs when VM virtual disks face data corruption. As a workaround, shutdown the VM gracefully, then power ON the VM, perform backup, and mount from the latest session.
Potential problem is detected when backing up a VMware VM with Changed Block Tracking enabled and residing on ESXi 6.0 or ESXi 6.0.x.
Symptom
Changed Block Tracking (CBT) returns incorrect changed sector list in ESXi 6.0 or ESXi 6.0.x. Arcserve UDP is potentially affected by the issue that results in inconsistent virtual machine backups (both full and incremental). For more details, see KB article .
If the problem occurs, the catalog job may fail and Recovery Point view may report errors.
Solution
VMware has released a patch for this issue. Apply this patch on your ESXi hosts.
For more details, see the VMware KB article or Arcserve KB article.
Agentless backup of SUSE Linux Enterprise Server 12 VM in Hyper-V fails and VM guest OS hangs after the backup.
Symptom
Due to a limitation in Windowsif the Hyper-V host is Windows 2012 R2 and VMs guest OS is SUSE Linux Enterprise Server (SLES) 12 with runlevel 5 (with graphical interface), the VM guest OS becomes unresponsive.
Solution
The same issue occurs while creating a VSS snapshot by using diskshadow command in the Hyper-V host. The compatibility problem is with Windows and SUSE.
Note: The issue is not related to Arcserve UDP .
Follow these steps to verify the problem:

Log into the Hyper-V Server.
Open the Windows Command Line as an administrator.
Perform the following steps:

Type diskshadow and press Enter.
Type add volume X: and press Enter.
Note: X: is the volume where the VMs virtual disk files and configuration file reside. If configuration file or VMs disk files are on different volumes, repeat this command to add all the volumes.
Type create and press Enter.
After the snapshot creation finishes, type end backup and press Enter.
Type exit and press Enter.

Verify if the VM guest OS hangs.
If the VM guest OS is not hung, verify Windows Event Log, Applications and Services Logs, Microsoft, Hyper-V VMMS, Admin. No workaround is available for one error log that indicates the failure of the VM during the snapshot creation. We recommend to work with Microsoft to solve the root cause. Alternatively, try to change the runlevel of SLES 12 from 5 to 3 (without graphical interface). However, no resolution is guaranteed.

Pre-flight check (PFC) reports failed to access the virtual machine for VMware VM.
Symptom
For VMware VM, pre-flight check (PFC) reports the following warning message for the Data Consistency:
Not verified because the application failed to access the virtual machine. Verify that the user credentials are correct and have administrative privileges.
Verify the provided proper credentials.
Solution
The issue is applicable only to PFC in VMware VM. Other features such as backup are not affected. As a workaround, install Arcserve UDP Agent on the machine that has installed Arcserve UDP Console (Agent service does not need to start).
Backup and restore using SAN transport fails and reverts to non-SAN transport mode when the provisioned size of VMs virtual disk is 4 TB or a multiple of 4 TB.
Symptom
Even when a SAN transport mode is possible, backup and restore jobs still use the HotAdd, NBD, or NBDSSL transport mode.
Solution
The issue is listed as a known issue in VMware.
Following are the patches released in VMware:

For ESXi 5.5 - Patch Release ESXi550-201504001 (2112672)
For ESXi 6.0 - Patch Release ESXi600-201505001 (2116125)

As a workaround, avoid using provisioned size that is in multiple of 4 TB. For example, do not use 4 TB or 8 TB; instead, use 3.9 TB or 8.1 TB.
When VMware Tools snapshot quiescing method is used, an Agentless backup of VMware systems backs up a corrupted snapshot.
Symptom
When you quiesce a VMware VM using VMware Tools, the snapshot contains corrupted data. The backup reads data from the snapshot and the data that is backed up also becomes corrupted. For more information about this issue, see the VMware KB article.
Note: The problem occurs with all VMware ESXi versions that has VM with guest OS Windows 2008 R2 SP1 and Windows 2012. Arcserve UDP cannot detect the data corruption problem because VMware does not return any error. You may face the problem only when restoring the data.
Solution
Perform the following tasks to detect and resolve the problem:

Recovery Point Check- Mount the volumes from the recovery point and verify data consistency by running the Microsoft tool CHKDSK while the backup job is ending. The chkdsk tool takes time to run. As a workaround, enable the option for weekly or monthly backup jobs.
Disable problematic writers in the guest OS of the VM- If the Recovery Point Check detects a problem, perform the steps described in How to check if you may be affected by this bug in the Arcserve KB article. As a workaround, VMware suggests to disable the VSS writers MSSearch Service Writer (ignore if not installed) and Shadow Copy Optimization Writer (typically present in every Windows VM) in the guest OS of the VM. You can manually perform according to the VMware KB article. Arcserve UDP also provides a simple way to disable the problematic writers during a backup. For more information, see link.

The Microsoft VSS inside VM snapshot quiescing method in a VMware VM may result in inconsistent backup.
Symptom
When using the Microsoft VSS inside VM snapshot quiescing method to back up a VMware VM, the backup may not be consistent. Especially, when backing up VM with applications (such as, Microsoft Exchange) installed.
Solution
As a workaround, use VMware Tools snapshot quiescing method by disabling the VSS writers MSSearch Service Writer and Shadow Copy Optimization Writer in guest OS of VM before this problem gets fixed.
After recovering a clustered VM to the original Hyper-V cluster, the network adapter fails to connect to the virtual switch and the following warning message appears in the activity log:
Unable to connect the network adapter <<adapter name>> to the virtual switch.
Symptom
When backing up a VM, failover happens for the clustered VM before taking a snapshot. Due to the failover, the Hyper-V host recorded in the backup session is inconsistent with the VM configuration.
Solution
You can manually connect the network adapter to a virtual switch on the Hyper-V host or use the Restore to an alternative location option to recover the VM that lets you set the restore configuration for the VM.
When you perform Incremental backup jobs for VMware virtual machines, the backed-up data size is at times larger than expected.
Symptom
Due to a VMware known issue, Changed Block Tracking (CBT) overstates change due to application-level quiescing.
Solution
The issue is fixed in VMware ESXi 5.5 or later and in VMware ESX 5.1 Patch 02. If VMware vCenter Server 5.5 manages any VMware ESXi 5.1 hosts, then the patch is applied. For more information on this fix, see the VMware KB.
If you still see the issue, then set the following registry on the proxy Server:
[HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\AFBackupDll\<VM instance UUID>]
"ResetCBT"=dword:00000001
Example:
[HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\AFBackupDll\502d3c43-e3c9-9919-78f9-89082ca5e1cc]
"ResetCBT"=dword:00000001
- Note: After the registry value is set, the next Incremental backup job converts to a Verify backup job and then the subsequent Incremental backup jobs continue to run with the appropriate size.
Due to a VMware known issue when the storage DRS is enabled and the storage vMotion occurs while the backup job is in progress, the backup job fails and the following message appears in the activity log:
Unable to open the VMDK file.
VMware reported the following error message:
A file was not found.
For more information, see the VMware KB Article 2055943.
The recovery of a VM with VMDK larger than 2 TB fails because the VM failed to create a snapshot.
Symptom
The backup source VM has VMDKs larger than 2 TB and the ESX/ESX(i) Server with a version lower than 5.5 can only support a virtual disk up to 2 TB disk in size. However, during the VM recovery, the following error messages appear:

In the vSphere Client:
- Create virtual machine snapshot VIRTUALMACHINE File <unspecified filename> is larger than the maximum size supported by datastore '<unspecified datastore>'.
- File is larger than the maximum size supported by datastore.
In the hostd log file for ESX/ESXi 4.x:
- Snapshot guest failed: The file is too big for the file system.
In the hostd log file for ESXi 5.0/5.1:
- Failed to do snapshot op: Error: (21) The file is too big for the datastore.

Solution
Due to a VMware limitation, the maximum size that VMware ESX/ESX(i) Server version lower than 5.5 supports is 2 T-16 GB that is equal to 2032 GB.
We recommend to use VMware ESX(i) Server 5.5 as the destination to perform conversion with a large disk.
For more information, see the VMware KB Article 1012384.
Creating a snapshot fails when more than seven disks are attached to a single SCSI (Small Computer heInterface) controller for a Windows VM running on an ESXi Server.
Symptom
When you run a backup job on a virtual machine containing a SCSI controller with more than 7 VMDKs, the backup job fails. The job fails because VMware requires maximum number of free slots for VMDKs on a particular SCSI controller to create a snapshot. An SCSI controller can have a maximum number of 15 slots. For example, if an SCSI controller has 7 VMDKs, a snapshot is created for each VMDK. A total of 14 slots are used with one slot free. If an SCSI controller has 8 VMDKs, the backup job fails because the snapshot is not created due to only 15 available slots.
- Note: Manual creation of snapshot also fails.
Solution
For virtual machines with more than seven disks on a single SCSI controller, perform the following steps:
1. Shut down the virtual machine.
2. Add one or more SCSI controllers by editing the VM in web client. If you are using VI client, you cannot add SCSI controller directly. Instead, additional controller is created when adding one more virtual disk and specifying non-existing Virtual Device Node numbers.
3. Distribute the existing disks between multiple SCSI controllers.
4. Power on the virtual machine.
Now you can create snapshots for each VMDK.
For more details, click link.
When you import VMware virtual machines from vCenter Server/ESXi 5.0 Update 3 and above while using HTTP protocol and port 80, the connection fails.
For more information about this known issue with VMware, click link.
An ESX/ESXi/vSphere 5.5 purple screen of death appears when an Arcserve UDP job runs.
Symptom
This is a known VMware issue affecting ESXi 5.0, 5.1, and 5.5 hosts and virtual machines using the E1000 and E1000e virtual network adapters.
- Note: This issue is resolved in the following VMware updates:

ESXi 5.0 Patch Release ESXi500-201401001. For more information, see the VMware KB.
ESXi 5.1 Update 2, available at VMware Downloads. For more information, see the VMware KB.
ESXi 5.5 Update 1, available at VMware Downloads. For more information, see the VMware ESXi 5.5 Update 1 Release notes.
ESXi 6.0 final, available at VMware Downloads. For more information, see the VMware ESXi 6.0 Release notes.

Solution
Switch to a VMXNET3 adapter. For more information, see the VMware KB Article 2059053.
During restore if the Hyper-V VM has child virtual disks then the data in the child virtual disks is merged to the corresponding parent virtual disk by creating a single image. The parent-child relationship does not exist after the VM recovery. As a result, the Difference Disks configuration is lost but you can recover the parent disk data. Data is not lost in this process as you can retrieve data from the single merged disk after the VM recovery also.
Note: For Agentless backup, you can manually configure the Differencing Disks after a successful VM recovery.
Import VM fails when duplicate VM instance UUID exists.
Symptom
When a VM is imported to the node view, the VM fails if another VM with the same VM instance UUID is already added to the node view.
A Host-based VM backup plan is saved. The plan fails when the selected proxy machine is installed with Arcserve D2D r16.5.
Symptom
When a Host-based VM backup plan includes a proxy machine that has the previous release of Arcserve D2D installed (for example, r16.5), the error message appears when the plan is saved.
Cannot find dispatch method
Solution
This problem occurs because the API of the current version is not compatible with the API of the previous version of Arcserve D2D. As a workaround, you can manually upgrade Arcserve D2D to the current version of the Arcserve UDP Agent (Windows).
The Host-based VM backup job may hang at the phase Starting Backup for a VM.
Symptom
The Host-based VM backup job hangs for hours and cannot proceed.
Solution
End afbackend.exe according to the process ID in the activity log, remove the VM snapshot if any, and submit the backup job again.
After performing a restore job for a Host-based VM and backup for Hyper-V virtual machine (VM), the status of the disks, except the boot disks on the recovered virtual machine is Offline.
Symptom
The behavior of the operating system creates the offline state by default.
The SAN policy was introduced in Windows Server 2008 to protect shared disks that are accessed by multiple servers. The default SAN policy from the source VM is “Offline Shared” for all SAN disks except the boot disk. Setting the policy to Offline enables the SAN disks to offline mode during startup. After recovery, a new disk for the VM is created. The disk file from the VM appears to be a SAN disk where the operating system identifies as offline. When the offline disk is set back as online, the disk remains online even after rebooting the system.
Solution
As a workaround, specify the DISKPART.exe command: SAN POLICY=OnlineAll setting for the source VM before backup because the disks are shared among other Servers, data corruption can occur. You must use the correct SAN policy to protect the data.
DISKPART.EXE command line
Query SAN policy:
DISKPART > san
SAN Policy: Offline Shared
Change SAN policy:
DISKPART > san policy=OnlineAll
DISKPART successfully changes the SAN policy for the current operating system.
Backup job for Linux VM hangs while taking snapshot.
Symptom
When backing up certain Linux based VM (For example, RedHat or SUSE) that resides on vSphere, the backup job hangs at taking snapshot stage.
Solution
Based on the VM, set the following registry value in the backup proxy machine to take the non-quiesced snapshot for backup:

For a certain VM:
[HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine\AFBackupDll\<vm-instance-uuid>]
DisableTakeQuiescenceSnapshot"=dword:00000001
Note: Replace <vm-instance-uuid> with the actual VM instance UUID that is found in the url after the agent logs in.
For all VMs protected by the proxy machine:
[HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine\AFBackupDll\]
DisableTakeQuiescenceSnapshot"=dword:00000001

Arcserve UDP Agentless backup always tries to take a quiesced snapshot. However, certain Linux kernel versions have a known issue with the vmsync driver that causes a deadlock if the same kernel is used while taking a VMware Snapshot with quiesce enabled. For more information, refer to the relevant kB article.
Copy to Tape job fails for the first recovery point if the VM is discovered and protected by Auto VM protection.
Symptom
Follow these steps to verify the problem:

Create an Agentless backup plan and add a container object in vSphere hierarchy (for example, a resource pool) into the plan. Set a local folder or shared folder as the backup destination and add a Copy To Tape task for the same plan.
Backup jobs for those VMs under the container object should run as per the schedule and after each backup job, Copy To Tape job is triggered for the copy recovery points to tape.
Add a new VM under that container object or move an existing VM into that container.
During the next schedule time, the first backup job is triggered automatically for the newly added VM. However, Copy to Tape job is not triggered after the completion of first backup job, so that the first recovery point is not copied. Copy To Tape job can be triggered successfully after the completion of second backup job.

Note: The problem occurs only when the backup destination is a local/shared folder or RPS.

Arcserve UDP switches to NBD/NBDSSL mode instead of SAN transport mode.
Symptom
If the ESXi data store name contains character @, SAN transport mode is not used due to VMware limitation, and Arcserve UDP switches to NBD/NBDSSL.
Solution
To use SAN transport mode, rename the ESXi data store and remove the character @.
File level restore, BMR, Virtual Standby, Instant VM, or Assured Recovery Test for a BitLocker Encrypted volume may fail.
Symptom
When UDP Agentless backup is performed for guest VM that has BitLocker Encrypted volume, the BitLocker encrypted volume is described as FAT32 volume in the activity log and unable to perform File level restore, BMR, Virtual Standby, Instant VM, or Assured Recovery Test for a BitLocker encrypted volume.
Solution
You can restore the BitLocker encrypted volume by recovering the whole guest VM.
The EFI or BIOS settings in VM are lost when you deploy VM from the restored template.

Symptom

When you deploy VM from the restored template, the customized settings in EFI or BIOS firmware are lost.

Solution

Manually set EFI/BIOS firmware settings again.

Restored Linux VM fails to boot up.

Symptom 1:

After restoring a generation 2 VM with Linux guest OS to Hyper-V server, the VM fails to boot up and displays one of the following error messages:

Boot Failed. EFI SCSI Device.

No Operation System was loaded. Press a key to retry the boot sequence...

Failed to open \EFI\BOOT\grubx64.efi - Not Found

Failed to load image \EFI\BOOT\grubx64.efi: Not Found

start_image() returned Not Found

Symptom 2:

After restoring a Generation 2 VM with Linux guest OS to Hyper-V server, the file boot entry was missed in the restored VM settings at the firmware level in Hyper-V Manager.

Solution

As a workaround, use the Instant VM feature to recover the VM or manually set the EFI boot loader in the guest OS of VM.

Follow these steps:

Attach the operating system (OS) ISO to the CD/DVD device of the VM and boot the VM into rescue mode.
Note: Different Linux distributions and versions may have respective methods to boot into the rescue mode. For more information, verify documents of corresponding distribution/version.
(Optional) Log on as root if prompted.
In the shell prompt, enter the following command:
efibootmgr --create --label <boot loader label> --disk <disk device> --loader <boot loader>
boot loader label – refers to any string such as CentOS
disk device – refers to the disk containing EFI System Partition (ESP) such as /dev/sda
boot loader – refers to the path and name of boot loader stored in EFI System Partition (ESP) such as \EFI\ubuntu\shimx64.efi.
Note: Different Linux distributions and versions may have different path and name as mentioned below.

Ubuntu- Always use \EFI\ubuntu\shimx64.efi
CentOS- Use \EFI\centos\shim.efi if the version of CentOS is 7 or above. Otherwise, search for a .efi file from /boot/efi/EFI/centos and specify as the loader name.
Redhat- Use \EFI\redhat\shim.efi if the version of Redhat is 7 or above. Otherwise, search for a .efi file such as \EFI\redhat\grub.efi from /boot/efi/EFI/redhat and specify as the loader name.
SUSE- Use \EFI\SuSE\shim.efi if the version of SUSE is 7 or above. Otherwise, search for a .efi file such as \efi\SuSE\elilo.efi from /boot/efi/EFI/SuSE and specify as the loader name.

Verify the added file boot entry in the VM setting of Hyper-V.
Reboot the system.

The restore job fails for Hyper-V VM that has two virtual disks with the same name.
Symptom
When you restore a Hyper-V VM that has two virtual disks with the same name to the same folder, the restore job fails with the following error:
Failed to create virtual disk [xxx], Error=[The file exists. (80)]
Solution
As a workaround, restore two virtual disks to different folders.
The Window Small Business Server 2011 guest OS is recognized as client version in VMware VM.
Symptom
If the VM has Windows Small Business Server 2011 guest OS, then Pre-flight Check (PFC) displays the following warning:
VMware does not support application-consistent quiescing for a VM running client versions of Microsoft Windows operating systems.
The VM's guest.guestFullName property is set with Microsoft Windows 7 (64-bit) due to a known issue in VMware. As a result, Arcserve UDP recognizes the VM as a client version of Windows.
Solution
As a workaround, ensure that Arcserve UDP uses the config.guestFullName VM property instead of guest.guestFullName. To make the change in Arcserve UDP Console and proxy machines, you need to add the VMwareVMUseConfiguredOS string value as 1 in the following path:
HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine
Note: You need to restart the Arcserve UDP Console service and agent service after adding the string value.
After applying ESXi 5.5 patch ESXi550-201609001, Arcserve UDP fails to connect to ESXi 5.5.
Symptom
After applying the patch ESXi550-201609001 (VMware KB2146717) on ESXi 5.5 host, the backup fails to start and import the VM node from the ESXi.
Note: The issue occurs only when the VM nodes are imported into Arcserve UDP directly from the ESX host. However, you can import the VM nodes from vCenter.
Solution
This issue occurs due to ESXi 5.5 patch ESXi550-201609001 where the TLSv1.2 protocol does not function properly. Arcserve is working with VMware to find the root cause. As a workaround, you need to disable TLSv1.2 manually.
Follow these steps:
1. Using any SSH client tool, connect to the ESX server.
2. Run the following commands in the command prompt:
  - esxcli system settings advanced set -o /UserVars/ESXiRhttpproxyDisabledProtocols -s "tlsv1.2"
  - ab. /etc/init.d/rhttpproxy restart
Hyper-V VM becomes slow after performing Arcserve UDP agentless backup job.
Symptom
If you perform the Arcserve UDP agentless backup job for Hyper-V VM, then the guest OS of Hyper-V VM becomes very slow as the backup job does not run for the OS. This issue occurs when the VM has huge (few TB) single virtual disk (VHD/VHDx) and the read/write operations are performed frequently inside the guest OS.
Solution
As a workaround, unload the Arcserve UDP Hyper-V CBT driver from the volume in which the VHD/VHDx file is present.
For more details or to get the patch for your Arcserve UDP environment, contact Arcserve support.
The backup job fails when you perform backup for VM that resides on ESXi 5.1.
Symptom
When you perform backup for VM that resides on ESXi 5.1 with Essential or Standard license applied, the backup job fails and the following error message is displayed in the activity log:
Unable to open VMDK file <VMDK file path and name>. VMware reported the following error: The host is not licensed for this feature. For more information, see the debug log <log file name>. If necessary, contact arcserve support.
Solution

This issue occurs due to the change of license check mechanism in VDDK 5.5. As a work around, you need to replace VDDK 5.5 with VDDK 6.0.2.

Follow these steps:

Download VDDK 6.0.2 package from the VMware website and extract files into a temporary folder.
Log into the agentless backup proxy machine.
Navigate to the following path:
C:\Program Files\Arcserve\Unified Data Protection\Engine\BIN\
Copy the VDDK5.5 folder to VDDK5.5-org for backup.
Delete the bin folder available in the following path:
Files\Arcserve\Unified Data Protection\Engine\BIN\VDDK5.5\BIN\VDDK64
Copy the bin folder available in the VDDK 6.0.2 downloaded package to the following location:
C:\Program Files\Arcserve\Unified DataProtection\Engine\BIN\VDDK5.5\BIN\VDDK64

You have replaced the VDDK 5.5 with VDDK 6.0.2 successfully.

The restore dialog displays incorrect name for the drive volume.
Symptom
If you perform VM or file-level restore from a recovery point of Hyper-V 2016 VM, the volume name is displayed as volume GUID instead of drive letter in the restore dialog.
Solution
This issue occurs due to a Microsoft known issue. For more information, refer to the relevant KB article.
Agentless backup fails.
Symptom
In vSphere v6.7, agentless backup fails for a VM due to the NVDIMM devices available in VM or if the virtual disks reside on PMem data store.
Solution
As a workaround, perform agent-based backup to protect the VM.
Failed to configure the static IP address for guest OS.
Symptom
In Hyper-V 2016 and 2019, the restored VM fails to configure the static IP address after the VM reboot. This issue occurs when you configure the static IP address in the guest OS of VM, perform agentless backup, and restore the VM.
Solution
As a workaround, configure the static IP address manually in the restored VM.
Additional virtual disks are backed up.
Symptom
When you run backup job of an agentless proxy VM and run the backup job for any agentless VMs associated to the respective agentless proxy VM using HotAdd transport mode simultaneously, the backup data of both the VMs is added to agentless proxy VM backup data.
Solution
As a workaround, you can use any of the following solutions:

Protect the agentless backup proxy using agent-based backup instead of agentless backup.
If you want to use agentless backup for the proxy VM, configure the NBD/NBDSSL transport mode prior to the HotAdd mode in agentless backup plans that use the backup proxy VM.
When the agentless backup job for the proxy VM is scheduled, ensure that no other agentless backup jobs run in the same proxy.

Cannot restore static IP Address of a Windows VM that is recovered to a Hyper-V on Windows Server 2016.
Symptom

When you recover the Windows VM to a Hyper-V on Windows Server 2016, the static IP settings on the recovered VM is lost if the VM has a static IP address.

Note: You can recover the MAC address; however, you can recover the static IP address only if the Hyper-V server is on a Windows Server 2012 or Windows Server 2012 R2.

Solution

After the VM is recovered, set the static IP address manually.