NetBackup status codes related to Hyper-V
Table: NetBackup status codes related to Hyper-V describes the NetBackup status codes that are related to Hyper-V.
For additional details on all NetBackup status codes, refer to the NetBackup Status Codes Reference Guide, available here:
http://www.veritas.com/docs/000003214
Table: NetBackup status codes related to Hyper-V
NetBackup status code | Explanation and recommended action |
|---|
1, the requested operation was partially successful | The problem may be one of the following: The problem may involve a virtual disk that is configured for Logical Disk Manager (LDM) volumes. See LDM volumes and status code 1. A snapshot of the virtual machine (*.avhd or *.avhdx file) was created while the backup was in progress. See Hyper-V snapshots (avhd or avhdx files) and status code 1. The virtual machine is configured with pass-through
disks. NetBackup for Hyper-V does not back up pass-through disks. If all of the virtual machine's disks are pass-through, note: Only the configuration files (such as XML, bin, vsv) that represent the virtual machine are backed up. To back up pass-through disks, see the following: See About Hyper-V pass-through disks with NetBackup.
|
42, network read failed | The Windows shadow storage for the volume may have insufficient space to hold all required snapshots. A larger shadow storage area may be required. See Viewing or resizing Windows NTFS shadow storage . |
48, client hostname could not be found | The problem may be one of the following: The NetBackup primary
server cannot communicate with the virtual machine. The host name of the virtual machine is not available. The NetBackup job details log contains the following message: Error bpbrm(pid=8072) Nameuse [0], VM [<vm name>]
not found on any node. Is either powered off or does
not exist. The virtual machine is either not running, or it is starting up.
Make sure that the virtual machine is running and then rerun the backup.
|
84, media write error | Incremental backups of the VM may fail if the NTFS file system in the guest OS is corrupted and the backup uses MSDP storage. This error may occur in the following case: The VMware or Hyper-V backup policy specifies Media Server Deduplication Pool (MSDP) storage.
The backup schedule includes incrementals (differential or cumulative). The NTFS file system in the VM's guest OS is corrupted. For example, the file system contains orphaned file record segments. The bptm debug log contains messages similar to the following: 16:24:04.604 [5720.7068] <16> 6:bptm:5720:win2012-2.hrous.sen.com:
[ERROR] PDSTS: fbu_fill_bitmap: (1945) stream_offset(610848768)
+ length(8192) > (1946) stream_offset(610848768)
16:24:04.604 [5720.7068] <16> 6:bptm:5720:win2012-2.hrous.sen.com:
[ERROR] PDSTS: fbu_scan_buf: fbu_fill_bitmap() failed
(2060022:software error) Use the chkdsk command to examine the file system in the guest OS and repair it as needed. Then restart the VM and rerun the backup.
|
156, snapshot error encountered | See Snapshot error encountered (status code 156). |
185, tar did not find all the files to be restored | If you attempt to do a full restore of two VMs at the same time, note: If the two VMs share a virtual hard disk that contains a file that both restore jobs must restore, a race condition may result. The two jobs may simultaneously attempt to access the same file, but only one job gains access to the file. The other job is denied access, and that job may fail with status code 185. After the first restore job successfully completes, retry the second job. |
2821 Hyper-V policy restore error | The problem may be one of the following: In a full virtual machine restore, the option was not selected: A virtual machine with the same GUID exists on the destination server. If a virtual machine with the same GUID exists on the destination server, you must select . In an SCVMM environment, the VM GUID is referred to as the VM ID. For individual file restore through a shared location on the destination virtual machine, one or more of the files is larger than 2 GB. Restore such files to a virtual machine that has a NetBackup client. (This issue does not apply to recovery of the full virtual machine.) In a restore of common files, the virtual machines that use the common files were in the Running or Paused state. The virtual machines that use the common files must be in the Off or Saved state. Otherwise, a virtual machine may have a lock on the common files. The virtual machine is highly available (HA). But the node that owns the virtual machine is not the restore server (the node that performs the restore). See Problems with restore of the full virtual machine. The virtual machine restore job fails but the virtual machine is nonetheless registered in the Hyper-V server. See Problems with restore of the full virtual machine. A redirected restore failed because the virtual machine is configured in a volume GUID and its differencing disk is configured in another volume GUID. See Restored virtual machine fails to start. From a backup that was made with the WMI method, the restore failed because it took too long to write the virtual disk. This error may occur if the VM has a large fixed virtual disk. See Increasing the WMI create disk time-out value.
|
4207, Could not fetch snapshot metadata or state files | For details on this status code, refer to the NetBackup Status
Codes Reference Guide: http://www.veritas.com/docs/000003214 |
4287, A NetBackup snapshot of the virtual machine exists and the policy option
specifies aborting the backup | For additional details on this status code, refer to the NetBackup Status
Codes Reference Guide: http://www.veritas.com/docs/000003214 |
