The following are some of the problems that can appear under status code 1:

• A file or a directory path is more than 1023 characters long.

  For NetBackup Snapshot Client, the maximum path name length is 1000 characters for snapshot backups, not 1023. When the snapshot is created, a new mount point is added to the beginning of the file path. If the new mount point plus the original file path exceeds 1023 characters, the backup fails with status code 1. The progress log includes the entry

  ERR-Skipping long dir path.

• You cannot open a file.

  The file may have been locked for some reason.

• The following information applies only to UNIX systems:

  NetBackup cannot get the link name of a file.

• The following information applies only to UNIX systems:

  NetBackup cannot process a sparse file.

• A read error that was encountered in a file.

• File is of an unknown type, or may be hidden.

• The following information applies only to UNIX systems:

  The lstat system call fails on a file that is eligible to be backed up. This error may be a permission problem.

• The following information applies only to UNIX systems:

  A file cannot be locked that has mandatory locking enabled.

• A synthetic backup job may terminate with a status code 1 under the following conditions:

  • No images were found to synthesize (status code = 607).

  • TIR information has been pruned from component images (status code = 136).

  • Image format is unsupported (status code = 79).

  The synthetic backup job logs the actual status code in the NetBackup error log. Refer to the documentation for the corresponding NetBackup error code for the corrective action to take.

• A BMR job may terminate with status code 1 in the following situation:

  You save the BMR configuration and it returns an error even though the child jobs completed successfully. For information, examine the Detailed Status tab of the Job Details dialog box, or the nbjm unified log (originator ID 117).

• A policy that contains multiple backup scripts starts a scheduled backup of a UNIX database extension client. If it fails with a status code 1, some of the backup scripts returned a failure status.

• On clients using Windows Open File Backups (WOFB) to back up open or active files, the following may occur:

  Volume snapshots were not enabled successfully for the backup.

  The following logging messages should appear in the bpbkar32 logs if volume snapshots were not successfully enabled.

  If multistreamed backup jobs are enabled, log messages similar to the following appear that indicate volume snapshots were not enabled for the multistreamed backup job:

  11:05:44.601 AM: [1536.724] <4> tar_backup::V_AddToFI_XBSAObj: 
  INF - Volume snapshots not enabled for: D:\Directory1

  If multistreamed backups were not enabled, log messages similar to the following appear, which indicate volume snapshots were not enabled for the non-streamed backup job:

  1:59:41.229 PM: [2076.2088] <4> 
  V_Snapshot::V_Snapshot_CreateSnapshot: INF - 
  ===============================
  1:59:41.229 PM: [2076.2088] <4> 
  V_Snapshot::V_Snapshot_CreateSnapshot: INF - Attempting to 
  create snapshots for D:\Directory1
  1:59:41.229 PM: [2076.2088] <4> 
  V_Snapshot::V_Snapshot_CreateSnapshot: INF - CREATE request: 
  C:\Program Files\VERITAS\NetBackup\bin\bpfis create -fim VSP 
  "D:\ Directory1"
  1:59:41.799 PM: [2076.2088] <4> 
  V_Snapshot::V_Snapshot_ParseBpfisOutput: INF - Snapshot 
  creation, FIS_ID: 1058813981
  1:59:41.799 PM: [2076.2088] <4> 
  V_Snapshot::V_Snapshot_ParseBpfisOutput: INF - Snapshot creation 
  EXIT STATUS 11: system call failed
  1:59:41.799 PM: [2076.2088] <4> 
  V_Snapshot::V_Snapshot_CreateSnapshot: INF - Snapshot creation 
  was not successful
  1:59:41.799 PM: [2076.2088] <4> 
  V_Snapshot::V_Snapshot_CreateSnapshot: INF - 
  ===============================

  In this case, examine the bpfis logs for error messages regarding snapshot creation failures. More details are available on the bpfis logs.

  See the NetBackup Snapshot Client Administrator's Guide.

  In the bpfis logs, the following messages may appear when snapshot creation fails for Windows Open File Backup:

  First message:

  04:01:14.168 [376.2364] <32> onlfi_fi_split: VfMS error 11; see 
  following messages:
  04:01:14.168 [376.2364] <32> onlfi_fi_split: Fatal method error 
  was reported
  04:01:14.168 [376.2364] <32> onlfi_fi_split: vfm_freeze_commit: 
  method: VSP, type: FIM, function: VSP_make
  04:01:14.168 [376.2364] <32> onlfi_fi_split: VfMS method error 
  3; see following message:
  04:01:14.168 [376.2364] <32> onlfi_fi_split: snapshot services: 
  snapshot creation failed: invalid argument(s).

  Cause: VSP was not enabled because the VSP snapshot for the backup did not meet the specified minimum time in the Busy File Wait VSP setting.

  Either increase the Busy File Timeout VSP setting (recommended setting: 300 seconds or more) or submit the backup job when the volume has less activity.

  Second message:

  04:17:55.571 [1636.3224] <2> onlfi_vfms_logf: snapshot services: 
  (null): There was an unexpected error while preparing the VSP 
  snapshot transaction. Dumping the parameter array to provide 
  more information: Error 112 from VSP_Prepare

  Cause: VSP was not enabled for the backup because the client for the VSP Snapshot Cache files does not have enough free disk space.

  Free up disk space on the volumes being backed up.

  Third message:

  If Microsoft Volume Shadow Copy Service (VSS) is used as the Windows Open File Backup snapshot provider and snapshot creation fails, refer to the following: Event Viewer's Application and System Logs for error information.

• A snapshot error may have occurred. Also, you may have some clients that use the Windows Open File Backup option to back up open or active files. In this case, a log message in the bpbkar32 debug log appears, which indicates that a snapshot error occurred.

  The following is an example of a snapshot error:

  8:51:14.569 AM: [1924.2304] <2> tar_base::V_vTarMsgW: ERR - 
  Snapshot Error while reading test.file

  See the recommended actions under status code 156.

• The backup of Microsoft Exchange Server included multiple databases, but not all of the databases were backed up successfully. Check the job details for statements about the databases that were not backed up. In a full or a differential backup, the transaction logs are truncated for any databases that are backed up successfully. The transaction logs can be restored from the backup image even if backups of other databases fail. Warning: Any database for which the backup has failed is unprotected by this backup.

• A granular-enabled backup of Microsoft Exchange Server successfully backed up the databases, but the second GRT phase to capture mailbox-level information failed. Check the job details for the cause of the failure. In a full or a differential backup, the transaction logs are truncated for any databases that are backed up successfully, regardless of whether the GRT phase succeeds. Any database that is backed up successfully can be restored from the backup image even if the GRT phase fails.

• During VMware backup, the virtual machine cannot be unlocked to allow storage migration.

  The virtual machine can be restored from this backup. However, you may want to correct this problem before the next backup.

• During VMware backup, the virtual machine snapshot cannot be deleted or the virtual machine's disks cannot be consolidated.

  The virtual machine can be restored from this backup. However, you may want to correct this problem before the next backup.

• During VMware restore, the virtual machine cannot be imported into vCloud. In the Activity Monitor, the Detailed Status tab of the job details includes messages from vCloud Director that indicate the reason for the error.

  The restored virtual machine is present on the destination vCenter. However, you must manually import it into vCloud.

• Clock discrepancy detected between NDMP filer and NetBackup 
  Media Server.

• If this is not expected, please perform a backup with Accelerator 
  forced rescan enabled.

• In order to stop seeing these messages, please address 
  clock discrepancy.

• If the NetApp filer and NetBackup NDMP backup host have a time difference of more than one hour, a clock discrepancy warning is displayed for all of the volumes.

  Check the time difference for the affected volumes and update as required. Or use a media server that is in the same time zone as the filer.

  Note:

  An NTP server is the recommended method to ensure the correct time.

• If any SnapMirror (Data Protection) volume has a lag time of more than one hour, the warnings appear for that volume.

  Use the following command to determine if the volume is a Data Protection volume and if the lag time is greater than one hour:

  • For NetApp Clustered Data ONTAP (cDOT):

    snapmirror show -fields lag-time

  • For NetApp 7-mode:

    snapmirror status

  If Data Protection volumes are found on the filer, either:

  • Browse to and select the volumes for backup in the Backup Selections for the NetBackup policy.

  • Use the VOLUME_EXCLUDE_LIST with the ALL_FILESYSTEMS directive to exclude the mirror volumes.

When a VMware agentless restore is performed, the restore can cause one of the following issues:

• Failed to detach the vmdk %s or the SCSI controller to which %s vmdk is attached from the destination VM %s during cleanup.

  Manually detach the vmdk or the controller.

• Deletion of temporary VM %s failed with error %d.

  Manually delete the specified VM.

• Failed to clean the staging location %s on destination VM %s.

  Manually delete the staging location.

• Failed to attach the temporary vmdk %s to the destination VM %s with error %d.

  Make sure that the target VM has at least one paravirtual controller with available LUNs.

• Failed to upload the process rename file to the destination VM %s with error %d.

  Make sure there is sufficient space available in target VM. Review the bpVMutil log file on the target VM for additional information on this issue.

• Failed to restore the selected files and folders.

  Review the tar log to troubleshoot this issue.

• Failed to identify the newly attached device on destination VM %s. One possible cause is that the destination VM user credentials have insufficient permissions. Veritas recommends destination VM user credentials have root or administrative privileges.

  Veritas recommends target VM user credentials with root or administrative privileges.