NetBackup™ Status Codes Reference Guide
- NetBackup status codes
- NetBackup status codes
- NetBackup KMS status codes
- NetBackup status codes
- Media Manager status codes
- Media Manager status codes
- Media Manager status codes
- Device configuration status codes
- Device configuration status codes
- Device configuration status codes
- Device management status codes
- Device management status codes
- Device management status codes
- Robotic status codes
- Robotic status codes
- Robotic status codes
- Robotic error codes
- Robotic error codes
- Robotic error codes
- Security services status codes
- Security services status codes
- Security services status codes
- NetBackup alert notification status codes
NetBackup status code: 5
Explanation: The following issues can cause this issue:
The vCPU for Azure was consumed past the threshold limit.
When you restore a replicated copy of EC2 instance to an alternate location, the key-pair names must be same on the source and the destination region.
The source snapshot is removed from the cloud provider.
The following are possible causes of granular restore failure:
Granular restore is not supported for the file systems and destination hosts that are created on LVM, LDM, storage pool, all variants of FAT, and volumes without drive letters.
The destination free disk space.
The destination file system was read-only.
Invalid destination path.
Before NetBackup Snapshot Manager version 10.0, vxms indexing was not supported. The granular restore (GRT) failed when a GRT is attempted from an older version of NetBackup Snapshot Manager and the source disk had lvm configured.
Recommended Action: To correct this issue, try the following solutions as appropriate:
If using Azure, contact your cloud provider to increase the threshold limit.
If you try to restore a replicated copy of EC2, create a new key-pair in the destination region. The new key-pair must be consistent with the key-pair in the source region.
Source snapshot must be retained on the cloud provider until the image expiration duration is selected in the protection plan.
When a VMware agentless restore is performed, the restore can cause one of the following issues:
Failed to upload recovery tool on destination VM %s with error %d.
Make sure there is sufficient space or permissions available at the staging location.
Failed to extract the recovery tool on the destination VM.
Confirm there is sufficient space available at the staging location %s in the target VM.
When a granular restore fails, perform the following:
For lvm and ldm disks granular restore, upgrade the Snapshot Manager to version 10.0.
Ensure that restore destination path is accessible with sufficient privileges and disk space.
The file wise restore error and warning report is available on source host (Windows or Linux) as follows:
Windows host path:
C:\ProgramData\Veritas\CloudPoint\restore\<job-id>/
Linux host path:
/root/veritas/<job-id>/
These locations provide the details of the disk wise restored file status.
For example:
D#.log -> Existing log file which shows higher level failure D#-Error.log ->This file is generated only when an error (at least one) is displayed during the copy process. This file logs the Actual Exception / OS exception. D#-Warning.log -> This file is generated only when a warning message (at least one) is displayed during the restore task.
Click here to view technical notes and other information on the Veritas Technical Support website about this status code.