Host-based VM Backup Related
- When the path length of a HBBU VM is more than 155 characters, the plan deployment fails and displays the following error message:
- Unable to apply 'plan' to proxy <proxy name>. (The backup destination path exceeds the maximum length 155.)
- The backup of Hyper-V Failover Cluster VM fails when you try to protect the node residing on partial Cluster Shared Volumes in which the deployed Hyper-V VM contains part of configuration files and disk files in CSV and Non-CSV storage.
- Unable to perform application restore as a VMware issue prevents taking quiesce snapshot for EFI booted Windows Server 2019 VM and fails to get VSS writer metadata. For more information about the known issue, refer to the VMware link.
- A VMware virtual machine backup fails when you add the virtual machine to the Console using HTTP. This failure happens as Arcserve UDP version 7.0 includes VMware Virtual Disk Development Kit (VDDK) that does not support HTTP. Refer to the SSL certificate and thumbprint checking now mandatory section in VDDK 6.0 release notes.
- If you need to use HTTP, download the latest version of VDDK 5.5.x and replace VDDK. For more information, see the link in Arcserve UDP Solutions Guide.
- For application granular level restore from that recovery points backed up from Hyper-V VMs, only database file dump is supported. The other options such as Restore to original location, Restore to recovery database, and Restore to alternative location are not supported.
- In Hyper-V VM, the Select virtual disks to be excluded from backup dialog box displays N/A for Type, Maximum Size, and Current Size fields if a virtual disk resides in SMB 3.0.
- When running multiple VMware backups simultaneously with transport mode as HOTADD, the backup job crashes. To resolve this issue, specify NBD or NBDSSL as the transport mode.
- While importing a VM from vCenter 5.5, when you select HTTP protocol to connect the vCenter, the VM infrastructure tree does not display any nodes.
- Restoring a Hyper-V virtual machine to an earlier version of the target Hyper-V Server is not officially supported. Nevertheless, you can still continue to restore it. However, due to the Hyper-V Server compatibility the restored virtual machine may not have full functionality.
- If you perform restore for a Hyper-V VM that has a virtual disk of size less than 12 MB, then the default size of restored virtual disk is 12 MB.
- The hypervisor of the VM changes due to either of the following reasons:
- If Arcserve UDP already has the new hypervisor connection information.
- The VM is detected under the new hypervisor after Update VM information is triggered.
- The VM is moved to a different hypervisor (and retained VM Instance UUID).
- The hypervisor hostname/IP is changed.
- Once that happens, you need to redeploy the plan to the VM to continue backups.
- For a Host-based Agentless backup of a Hyper-V VM with replication enabled:
- The Host-based Agentless backup supports backing up the VM from the Master (primary) site.
- The Host-based Agentless backup for the Replica site is not guaranteed with data consistency, accuracy, and the completion of the backup job.
- The iSCSI hard disk that is attached to a virtual machine is not backed up.
- Symptom
- After backing up a VM, the volumes on iSCSI devices are not listed in the restore UI and you cannot perform agentless backup for the volumes that reside in external storage such as iSCSI.
- Solution
- As a workaround, create an Agent-based backup plan in Arcserve UDP or use Arcserve UDP Agent (Windows) to back up the virtual machine.
- After upgrading to Arcserve UDP Version 7.0, the first Hyper-V VM backup includes the full content of the disk (even if it is an Incremental Backup). The log may display the following message:
- The Change Block Tracking (CBT) feature has been upgraded. As a result, redundant data may be backed up.
- The following limitation is from Hyper-V, and not from Arcserve UDP . From Windows 2012 R2 onwards, a new feature of Hyper-V named shared VHD is available. This feature allows you to share the VHD(X) file among multiple VMs.
- For more information, see this blog. However, Hyper-V VSS Writer does not support this new feature. As a result, a Hyper-V Agentless backup of VM containing the shared VHD feature fails. To back up such VMs, perform an Agent-based backup by installing Arcserve UDP Agent (Windows) on the VM.
- From Windows 2016 onwards, a new feature of Hyper-V named shared VHD set is available. This feature allows you to share the VHDS file among multiple VMs. Arcserve UDP cannot backup VM with shared VHD set for Host-based agentless job. As a workaround, perform Agent based backup.
- In the Storages and VMs inventory view where you can add VM nodes into agentless backup plan if two VMs reside in the same SMB 3.0 share and use different host names or IP addresses to connect to the SMB 3.0 share, then they are displayed in different storage node in the tree view.
- For example:
- If two VMs VM1 and VM2 that reside in the same SMB 3.0 share hosted in server ABC where VM1 uses connection \\ABC\share and VM2 uses connection \\ABC.domain.com\share, then the VMs are displayed as different storage nodes such as \\ABC\share and \\ABC.domain.com\share in the tree view.
- Arcserve UDP does not support the backup and restore operations of Hyper-V agentless VMs using SR-IOV.
- Host-based Agentless backup does not support vCenter Servers using VMware Linked mode. To protect VMs that reside on vCenter Server instances in Linked Mode groups, add each VM individually from the vCenter Server.
- VM recovery job may fail when the VM is backed up from a higher version ESX and restored to a lower version directly (not through vCenter). For example, you backup from ESXi 6.0 and restore to a lower version of ESXi, such as ESXi 5.5.
- Symptom
- If the VM is backed up from a higher version ESXi (such as ESXi 6.0), when restoring to a lower version ESXi (such as ESXi 5.5) directly (not through vCenter), the VM recovery job may fail displaying the following error message:
- VM recovery job was unable to create the new virtual machine. The ESX/vCenter Server system reported the following error: com.sun.xml.internal.ws.fault.ServerSOAPFaultException: Client received SOAP Fault from Server: Unexpected element tag "uptCompatibilityEnabled" seenwhile parsing serialized DataObject of type vim.vm.device.VirtualE1000 at line 1, column 5452while parsing property "device" of static type VirtualDevice
- Solution
- This issue occurs due to compatibility problem of the VM created in different versions of ESXi. The VM property is introduced in the higher version ESXi but not supported by lower version ESXi. You can use one of the following workarounds:
- Before backup, remove the device that has the unsupported property.
- Restore the VM through vCenter that has the same version of ESXi. For example, in the above scenario use vCenter 6.0.
- Manually create the VM on lower version of ESXi and restore the VM by BMR. This option is applicable only to VM with Windows guest OS.
- If you use auto protection to protect the whole Hyper-V cluster with VM configured as cluster role first and then remove the VM from cluster (or vice versa), then incremental backup is converted to full/verify backup.
- Follow these steps:
- Configure VM as cluster role.
- Create a plan with auto protection to protect the whole cluster.
- Perform backup for the plan.
- Remove the cluster role for VM.
- Perform incremental backup for the plan. Now, backup job for the VM is converted to a full or verify backup.
- The On exit code option available for agentless backup plan in Advanced tab does not work for Hyper-V VM.
- Arcserve UDP 7.0 allows to add a tag into agentless backup plan and protect the VMs automatically. However, the tags are supported only for vCenter 6.0 and 6.5.
- In Arcserve UDP 7.0, the Host-based Agentless backup supports Hyper-V VM files residing on Microsoft SMB 3.0. For such VM, the downgraded backup throughput is observed when the following conditions are met:
- Hardware snapshot is possible for the Hyper-V VM.
- The Use hardware snapshot wherever possible option is selected in the backup plan.
- The backup proxy is the same machine of Hyper-V host.
- In vSphere 6.5, the customized settings set in EFI or BIOS firmware are lost while performing the restore of encrypted VM.
- Symptom
- In vSphere 6.5, if you modify the EFI or BIOS firmware settings for an encrypted VM, perform backup first and then restore for the VM, then all the settings in EFI and BIOS firmware are reset to default values and the modifications are lost.
- The symptom occurs due to the following scenarios:
- If you restore the VM as a non-encrypted VM, then the EFI/BIOS settings are lost as the encrypted NVRAM file is not associated to non-encrypted VM.
- If you restore the VM as encrypted VM and select Restore to an alternative location option, then the EFI/BIOS settings are lost as the security key restore to the VM fails and the encrypted NVRAM file becomes inaccessible.
- For BIOS OS, usually the file system of system volume is NTFS, but in some rare cases the system volume is FAT32. If the system volume is FAT32, UDP does not backup the system volume when performing the full machine backup.
- UDP does not support backing up SQL server writer using Host-based VM backup if the vSphere has encryption enabled. According to the VMWare link, application quiescing is not supported for the encrypted VMs, which prevents UDP from detecting the SQL writer.
- Arcserve UDP does not support backing up SQL server writer using Host-based VM backup if the vSphere has encryption enabled. According to the VMWare link, application quiescing is not supported for the encrypted VMs, which prevents UDP from detecting the SQL server writer.
Note: The limitation is observed only for hardware snapshot. As a workaround, you can select Use software snapshot only option in the backup plan.
Solution
As a workaround, restore the VM as encrypted VM and select Restore to original location option or manually set the EFI/BIOS firmware settings again after restoring the VM.