Error while restoring AHV virtual machines

The following table describes the problem that might occur when you restore an AHV virtual machine.

Table: Error run into while restoring AHV virtual machines

Error message or cause	Explanation and recommended action
VM recovery to alternate location fails on a Windows primary server.	For a windows NetBackup primary server, ensure that the rename file ends with an empty line.
Unable to change the AHV cluster while modifying the recovery destination.	If you cannot see the list of the AHV clusters, you might not have access to the AHV clusters in RBAC. Contact the NetBackup security administrator to resolve this issue.
Pre-recovery check runs successfully when a VM with the same UUID exists in the AHV cluster and the option to overwrite the VM is not enabled, but the VM restore fails. The following error message is seen: Info bpVMutil (pid=1196) FTL - Virtual machine exists and overwrite option not specified, cannot proceed with restore. End Restore; elapsed time Hypervisor policy restore error. (2822)	Pre-recovery check compares the VM display name instead of UUID to find out if VM already exists, hence the check completes successfully. But if the overwrite option is not set, the restore job fails if a VM with the same UUID already exists. Workaround: Restore the VM with a new UUID Start the recovery process. On the Recovery Options page, click Advanced. Enable Create a new VM UUID. Proceed with the recovery process and click Start recovery to restore. Overwrite the existing VM that has the same UUID Start the recovery process. On Recovery Options page, enable the Overwrite existing virtual machine option. Proceed with the recovery process and click Start recovery to restore.
When you try to recover an AHV VM image that is imported from a different domain using the web UI, the pre-recovery check fails and displays that by default the recovery host is the same access host that was used during back up.	During the recovery of imported AHV VM images, for the recovery host, select the access host in the target domain as a recovery host or select the target primary server.
MSiSCSI service is disabled. Enable the MSiSCSI service on the recovery host.	Enable Microsoft iSCSI Initiator Service (MSiSCSI) service on the windows backup recovery and re-run the job.
Failed to connect to the recovery host.	The recovery host used for agentless restore is not reachable. Recommended action: Ensure that recovery host is reachable from primary server and has a NetBackup media or client installed on it.
The specified recovery host must be at NetBackup version 9.1 or later to support agentless restores.	Agentless restores of files or folders require recovery host with NetBackup version 9.1 or later. Recommended action: Verify the NetBackup version on recovery host. It should be 9.1 or above. On UNIX NetBackup servers and clients, check the `/usr/openv/netbackup/bin/version` file. On Windows NetBackup servers, check the `install_path\netbackup\version.txt` file.
Recovery host staging location does not exist.	staging location path does not exist on recovery host for agentless restore. Recommended action: Ensure that the default staging location path or the user-configured staging location path for recovery host is valid. NetBackup uses the following on recovery host or as default staging location: For UNIX: `{installpath}/openv/tmp/staging`. For Windows: `{installpath}\Netbackup\Temp\staging\`. Ensure that the staging location path that is used exists. For user-configured staging location, check if valid path on recovery host is specified in `bp.conf` parameter `AGENTLESS_RHOST_STAGING_PATH = "path"`.
Tar image not found at staging location on recovery host.	No tar image was found on recovery host staging location which is required for agentless restore. Recommended action: Contact Veritas Technical support and share `bpVMutil` log from the recovery host.
Internal error has caused failure of recovery validation.	Internal error was occurred while executing Pre recovery validations for agentless restore. Recommended action: Save the bpVMutil logs on recovery host and contact Veritas Technical support.
Not enough space available on recovery host.	The recovery host may not have enough space to copy the selected files at staging location for agentless restore. Recommended action: Ensure that sufficient free space is available on the recovery host staging location based on the total size of files or folders selected. Or select a different recovery host with sufficient free space for performing agentless restore.
Tar utility is not present on the target host.	Failed to find tar utility on the target host, required for agentless restore. Recommended action: Retry after deploying the tar utility.
Either specified staging location does not exist on target host or the user does not have required permission to access.	Recommended action: Ensure that the target host staging location exists, and the user has sufficient permissions to access the location.
The user does not have required permission on the target host staging location	The user does not have required permission to proceed with restore on the target host. Recommended action: Ensure that the target host staging location exists and the user has minimum Write and Execute permission on the staging location.
The user does not have root/administrator privileges. To restore files and folders, provide user with root/administrator privileges.	The user does not have required permission to proceed with restore on the target host. Recommended action: Provide the credential which is part of local administrator group on the Windows target host. For Linux target host, use the credential which is root or sudo account with ALL permissions.
Admin share of target host is not accessible from the recovery host.	Admin share of remote host is not accessible from the recovery host to perform agentless restore. Recommended action: Ensure that firewall exceptions are set up correctly. Ensure that File and Printer Sharing is enabled. Ensure that GPO/Software Restriction Policy or Antivirus is not blocking access. Ensure that target host is accessible and ensure that the correct credentials are entered and have proper permissions.
For agentless files or folders restore in User Account Control (UAC) environment, please provide credential of domain user which is part of local Administrator group on the Windows target host.	Recommended action: For agentless restore in User Account Control (UAC) environment, provide credential of domain user which is part of local Administrator group on the windows target host.
Agentless restore is not possible.	Received unexpected reason for agentless restore failure. Recommended action: Contact Veritas Technical support and share appropriate logs.
Operating systems do not match. Ensure that the operating system of recovery host matches with the backed-up VM operating system.	Agentless restore is possible only when operating system of recovery host and backed up VM is same. Recommended action: Use alternate recovery host of the same operating system as that of backed up VM.
Failed to retrieve the backup image operating system.	Unable to retrieve operating system of backup image for performing agentless restore. It is an internal error.
Recovery host operating system is not compatible with provided communication mode. Ensure that the operating system of recovery host and provided communication mode are compatible.	Recovery host OS type and communication type provided in the agentless recovery or pre-recovery check request are not compatible. Recommended action: Verify that Recovery host OS type and Communication type must be compatible. If recovery host is: Linux: Communication type must be SSH. Windows: Communication type must be WMI.
Target host SSH private key is invalid.	The 'sshKey' field of the agentless recovery or pre-recovery check request must be valid and non-empty ssh private key of target host. Recommended action: Verify that the `sshKey` field is specified, if the authentication type is SSH_KEY and that it is not empty.
Target host operating system is not supported for the agentless files or folders restore.	Target host operating system is not supported since agentless restore requires recovery packages to be deployed on target host. Recommended action: Only SUSE Linux Enterprise Server, Microsoft Windows, Red Hat Enterprise Linux (RHEL), and Ubuntu are supported platforms. Refer to the NetBackup Client Compatibility List for the supported platforms for this feature at the following URL:\nhttp://www.netbackup.com/compatibility.
Invalid target host username or password.	The username and password fields in authentication details of the agentless recovery or pre-recovery check request must be specified. Recommended action: Verify that the username and password field in authentication details of the recovery and pre-recovery check request are specified, correct, and are not empty.
Target host staging location path contains non-ASCII characters.	Target host staging location path supports ASCII characters only. Recommended action: Provide custom staging location on target host with ACSII characters only.
Specified path does not exist on the local disk	Target host staging location should not be the network path. Recommended action: Specify a custom staging location on target host which is on its local disk.
WMI connection to the target host is failed.	WMI connection to the target host is failed from recovery host. Recommended action: To connect with WMI and DCOM service, user must have the required permission to connect with the remote WMI service. Firewall exceptions are set up to allow WMI traffic through the firewall. GPO/Software restriction policy or an antivirus is not blocking the access. Ensure that target host is accessible. Validate the given target host credentials. Ensure that the target host trust relationship with domain is intact. When you communicate across domains, two-way trust relationship between those domains must exist.
Unable to find the specified file on the remote server.	Unable to find the specified file on the remote server. Recommended action: Ensure the specified staging location on target host exists or specify another valid staging location.
File exists with same name as the directory.	There is a pre-existing file on target host with same name as that of directory path provided as staging location. Recommended action: Check for a pre-existing file on remote host with the same name and path as that of staging location. If it exists, either rename or remove that file. Or specify an alternate staging location.
Failed to validate administrative privileges for the user.	Target host user doesn't have the administrative privileges for the agentless files and folders restore operation to proceed. Recommended action: Use the credential which is part of local administrator group on the Windows target host. For Linux target host, use the credential which is root or sudo account with ALL permissions.
Failed to connect a network resource using windows API.	Admin share of target host is not accessible from the recovery host for agentless files or folders restore. Recommended action: As a part of agentless files and folders restores operation, SMB Admin share is created from recovery host on target host with the credential provided by user. This error is usually seen when target host for agentless restore has windows OS and admin share of target host is not accessible from the recovery host. Ensure that following things on target host. Firewall Exceptions are set up correctly. File and Printer Sharing is enabled. GPO/Software restriction policy or antivirus is not blocking access. Target host is accessible with valid credentials.
Unable to retrieve user's home directory on the target host. Specify the custom staging location.	User's default staging location, that is home directory cann't be retrieved on the target host. A valid custom staging location path must be entered by user. Recommended action: Ensure that user's home directory exists or try with a valid custom staging location.
Failed to establish SSH session with host.	Ensure all of the following criteria are satisfied and then retry. aes256-ctr is the supported cipher used for communication. Ensure that this cipher is supported both in recovery host and target host. Ensure at least one of the following the Hash-based Message Authentication Code (HMAC) protocol is supported on both recovery host and target host: hmac-sha2-256 hmac-sha2-512 Ensure the method used for generating host key is one of the following: ECDSA_SHA2_NISTP256 ECDSA_SHA2_NISTP384 ECDSA_SHA2_NISTP521 SSH_RSA SSH_DSS
Failed to verify SSH key fingerprint of host.	SSH key fingerprint of target host provided is not correct. Recommended action: Verify the SSH key fingerprint of the target host and retry.
Failed to authenticate the host with provided username or password.	Target host authentication is failed with the provided username and password. Recommended action: Verify the username or password of the target host is correct and retry.
Failed to authenticate the host with specified SSH key.	Target host authentication is failed with the provided SSH private key. Recommended action: Verify the SSH private key along with key passphrase if used to generate SSH private key of the target host and retry. Ensure that the corresponding public key is present in the authorized_keys file in /root/.ssh folder at the target host.
Matching SSH Key fingerprint host key method not found on target host.	Unable to find the specified SSH key fingerprint host key method on the target host Recommended action: Ensure that either supported host key method of the specified SSH key fingerprint is available on target host or provide SSH fingerprint of the host key method that is configured on target host.
The restore fails when you restore individual files to a virtual machine that has NetBackup client software.	When you restore individual files to a virtual machine that has a NetBackup client, make sure that a firewall does not interfere with the restore. If a firewall stops the restore, turn off the firewall and retry the restore.
Mount points not available when restoring files from a Linux virtual machine.	For Linux virtual machines, only the `ext2`, `ext3`, `ext4` and `xfs` file systems are supported for individual file restore. If a partition is formatted with some other file system, the backup succeeds but NetBackup cannot map the file system addresses of the files. As a result, NetBackup cannot restore individual files from that partition. Only the files that were on `ext2`, `ext3`, `ext4` and `xfs` partitions can be individually restored. Note: To restore individual files from their original mount points, the "/" (root) partition must be formatted as `ext2`, `ext3`, `ext4` or `xfs`. If the "/" (root) partition is formatted with a different file system such as ButterFS, the mount points cannot be resolved. In that case, you can restore `ext2`, `ext3`, `ext4` or `xfs` files from the /dev level (such as /dev/sda1). You cannot restore the files from their original mount point level.
For Linux VMs without persistent device naming, multiple disk controllers such as IDE, SCSI, and SATA may complicate the recovery of individual files.	This issue occurs because of non-persistent device naming, such as `/dev/sda and /dev/sdb`, may cause unexpected mount point changes after a restart. If the VM has a SCSI disk and SATA disk, the Restore files and folders > Add files and folders navigation interface may show incorrect mount points for the VM's files. For example, the files originally under `/vol_a` might appear under `/vol_b` when you browse to restore them. The restore is successful, but the restored files may not be in their original directories. Recommended action: Search for the files on the restored VM and move them to the proper locations. To prevent this issue on Linux VMs with multiple disk controllers, Veritas recommends a persistent device-naming method for mounting the file systems. When persistent naming is in place, device mounting is consistent and this issue does not occur when you restore files from future backups. For persistent device naming, you can mount devices by UUIDs. The following is an example of the `/etc/fstab` file that contains the devices that are mounted using UUIDs: UUID=93a21fe4-4c55-4e5a-8124-1e2e1460fece /boot ext4 defaults 1 2 UUID=55a24fe3-4c55-4e6a-8124-1e2e1460fadf /vola ext3 defaults 0 0 To find the device UUIDs, you can use either of the following commands: blkid ls -l /dev/disk/by-uuid/
For Ubuntu VMs without persistent device naming, the Restore files and folders > Add files and folders navigation interface may show incorrect mount points for the VM's files and recovery of individual file may fail.	This issue occurs because of non-persistent device naming and may cause unexpected mount points changes. For the Ubuntu VM, the Restore files and folders > Add files and folders navigation interface may show incorrect mount points for the VM's files. For example, files and folders might appear under `/dev/ubuntu-vg/ubuntu-lv` when you browse to restore them and recovery of individual files may fail. Recommended action: To prevent this issue on Ubuntu VMs, Veritas recommends a persistent device-naming method for mounting the file systems. When persistent naming is in place, device mounting is consistent and this issue does not occur when you restore files from future backups. For persistent device naming, you can mount devices by UUID. The following is an example of the `/etc/fstab` file that contains the devices that are mounted using UUIDs: UUID=93a21fe4-4c55-4e5a-8124-1e2e1460fece /boot ext4 defaults 1 2 UUID=55a24fe3-4c55-4e6a-8124-1e2e1460fadf /vola ext3 defaults 0 0 To find the device UUIDs, you can use either of the following commands: blkid ls -l /dev/disk/by-uuid/
Unable to perform agent-based restore if the elected target host is Linux 8.1.	NetBackup does not support agent-based restore for 8.1 Linux platform. In case of NetBackup 8.1, agent-based restore is supported for windows platform only and not for Linux platform. Recommended action Upgrade Linux target host to 8.2 or later for agent based restores.

Error while restoring AHV virtual machines

Feedback

Feedback