Troubleshooting - Image Level iDataAgent

  • This product is deprecated for AIX and Linux. New installations of the Image Level Agent are no longer supported in V10, but the agent will continue to function normally. Upgrade to the latest service pack in V10 is supported. You cannot use your installed version of the Image Level Agent to perform backups in the next version of SnapProtect.
  • This functionality is now available using Block-Level Backup. We recommend that you begin backing up data by using the block-level backup method instead of using the Image Level Agent as soon as you are able to. No new license is required for Block-Level Backup. For instructions on transitioning to block-level backups, see Transitioning from Image Level Agent to Block-Level Backups.

See Deprecated Features, Products, and Platforms for comprehensive information on deprecated products.

The following section provides information on troubleshooting restores.

Browse Failures

Point-in-Time Table Browse Failures When you have encryption enabled for the client, point in time table browse operation fails with the following error message:

Pass-phrase protection is on for client [80], but pass-phrase was not specified.

Make sure that the pass phrase is exported to the MediaAgent when encryption is enabled for the client.

  1. From the CommCell Browser, right-click the client and select Properties.
  2. Click the Encryption tab.
  3. Click Via Pass-Phrase.
  4. Click Export.
  5. In the Destination Computer box, select the MediaAgent.
  6. In the Pass-Phrase box, type the pass-phrase used for encryption.
  7. In the Re-enter Pass-Phrase box, re-type the pass-phrase to confirm.
  8. Click Export.
  9. Click OK.

Restore Failures

XFS Volume Restore Failures Out-of-place restore of an XFS volume fails with the following error message:

CVVolumeUnix::Unlock:() - failed to mount=/dev/mapper/imgdcvg-lvol3 to mntpath=/xfsrest errno=9 mount it manually
CVVolumeUnix::Unlock:() - !!USER intervention required for mounting=/dev/mapper/imgdcvg-lvol3 to mntpath=/xfsrest manually

This is because the source and destination volumes have the same UUID. You can resolve this in one of the following ways:

  • Mount the files system with NOUUID option. For example:

    mount -o nouuid /dev/sdb7 disk-7

  • Generate a new UUID for the partition using the xfs_admin utility and then mount the XFS volume. For example:

    xfs_admin -U generate /dev/sdb7

Completed with one or more errors

Restore jobs from Windows File System iDataAgent will be displayed as "Completed w/ one or more errors" in the Job History in the following cases:

For subclient containing only system state restore:

  • Fails to restore critical component - the job status is failed
  • Fails to restore non-critical component - the job status is completed w/ one or more errors

For subclient containing system state restore along with File system data:

  • Failure to restore critical component - marks the job as completed w/ one or more errors, so the data can be recovered.
  • Failure to restore non-critical component - marks the job as completed w/ one or more errors

IMFS0005: Inconsistency in file-level browse

If the backed up volume was formatted with an allocation unit size less than 1024 bytes, some files may be missing from the file level browse. The allocation unit size must be at least 1024 bytes for file level browse to function correctly.

IMFS0006: Volume-level restore failure with error: "Failed to freeze target volume"


Volume-level restore fails with the following error:

Failed to freeze target volume


You will get this error message if, for some reason, the restore process cannot lock the destination volume (the volume you want to restore to). Possible causes include:

  • Snapshot active on the target volume (run the vssadmin list shadows command).
  • Target volume is mapped on another machine (check sessions on your destination machine, this may require a reboot).
  • Persistence is set incorrectly on the target volume.
  • Target volume is open.
  • Target volume has live application data on it (check Exchange System Manager or SQL Enterprise Manager to see if you are restoring to a volume.
  • Sometimes this will happen if you have Exchange System Manager open and you are moving Exchange data (even if it is stale Exchange data).

IMFS0007: File-level restore failure

File-level restores may fail if the Index Cache of the MediaAgent resides on a non- NTFS volume.

IMFS0008: Restored volume is corrupt (wrong cluster size)


When performing a volume level restore, the destination volume gets corrupt if the cluster size used for the backup does not match the default cluster size required for the size of the destination volume.

For example, if you restore a volume that was backed up using a 4 KB cluster size to a destination volume of 18 TB, the restored volume gets corrupt because the default minimum cluster size for an 18 TB volume is 8 KB.  The maximum size of a volume that can use a 4 KB cluster size is 16 TB.


NTFS volumes allocate hard disk space using increments of cluster sizes. A cluster is a smallest fixed unit of disk space that can be allocated to a file. For file sizes that are not an exact multiple of the cluster size, additional space must be allocated as the next largest multiple of the cluster size.

If the cluster size is not specified when formatting a partition, defaults are used according to the size of the partition, to reduce the amount of unused space and reduce fragmentation. You can override the default settings when formatting a partition.

For example, the default maximum cluster size for NTFS under Windows NT 4.0 and later is four kilobytes and NTFS file compression is not supported on drives with a larger cluster size.


When restoring volumes, the backed up cluster size determines the maximum cluster size for the destination volume. For volumes over 16 TB, you must use a larger cluster size.

Ensure that the restored volumes use the required default cluster sizes for NTFS as listed in the following table.

Volume size Windows NT 3.51 Windows NT 4.0 Windows 7, Windows Server 2008 R2, Windows Server 2008, Windows Vista, Windows Server 2003, Windows XP, Windows 2000
7 MB–512 MB 512 bytes 4 KB 4 KB
512 MB–1 GB 1 KB 4 KB 4 KB
1 GB–2 GB 2 KB 4 KB 4 KB
2 GB–2 TB 4 KB 4 KB 4 KB
2 TB–16 TB Not Supported* Not Supported* 4 KB
16TB–32 TB Not Supported* Not Supported* 8 KB
32TB–64 TB Not Supported* Not Supported* 16 KB
64TB–128 TB Not Supported* Not Supported* 32 KB
128TB–256 TB Not Supported* Not Supported* 64 KB
> 256 TB Not Supported Not Supported Not Supported

* Not supported because of the limitations of the master boot record (MBR).

Windows limits the size of an NTFS volume to that addressable with 32-bit clusters, which is slightly less than 256 TB (using 64-KB clusters).

For more information, refer to Microsoft KB article 140365.

IMFS0009: Corruption on target volume (the volume you restored to)

Possible causes include:

  • The source or target volume is zoned through the SAN for multiple machines besides your client machine.
  • Snap was not actually taken before copying, or we are copying from the disk instead of the snap.
  • Hard booting a machine (Blue Screen of Death, power loss) where the subclient content volumes do not have persistence ON.
  • Defragmenting a volume containing the QSnap cache (you should never defragment the cache volume while a job is running).

Recovering data associated with deleted clients and storage policies


In a disaster recovery scenario, use the following procedure to recover data associated with the following entities:

  • Deleted storage policy
  • Deleted client, agent, backup set or instance

Before You Begin

This procedure can be performed when the following are available:

  • You have a Disaster Recovery Backup that contains information on the entity that you are trying to restore. For example, if you wish to recover a storage policy (and the data associated with the storage policy) that was accidentally deleted, you must have a copy of the disaster recovery backup that was performed before deleting the storage policy.
  • Media containing the data you wish to recover is available and not overwritten.
  • If a CommCell Migration license was available in the CommServe when the disaster recovery backup was performed, no additional licenses are required. If not, obtain the following licenses:
    • IP Address Change license
    • CommCell Migration license

    See License Administration for more details.

  • A standby computer, which is used temporarily to build a CommServe.
Recovering Deleted Data
  1. Locate the latest Disaster Recovery Backup that contains the information on the entity (storage policy, client, agent, backup set or instance) you are trying to restore.
    • Check the Phase 1 destination for the DR Set or use Restore by Jobs for CommServe DR Data to restore the data.
    • If the job was pruned and you know the media containing the Disaster Recovery Backup, you can move the media in the Overwrite Protect Media Pool. See Accessing Aged Data for more information. You can then restore the appropriate DR Set associated with the job as described in Restore by Jobs for CommServe DR Data.
    • If the job is pruned and you do not know the media containing the Disaster Recovery Backup, you can do one of the following:
      • If you regularly run and have copies of the Data on Media and Aging Forecast report, you can check them to see if the appropriate media is available.
      • If you do not have an appropriate report, and know the media that contains the DR Backup, catalog the media using Media Explorer. Once the cataloging process is completed, details of the data available in the media are displayed.
  2. On a standby computer, install the CommServe software. For more information on installing the CommServe, see Install the CommServe.
  3. Restore the CommServe database using the CommServe Disaster Recovery Tool from the Disaster Recovery Backup described in Step 1. (See CommServe Disaster Recovery Tool for step-by-step instructions.)
  4. Verify and ensure that the NetApp Client Event Manager NetApp Communications Service (EvMgrS) is running.
  5. If you did not have a CommCell Migration license available in the CommServe when the disaster recovery backup was performed, apply the IP Address Change license and the CommCell Migration license on the standby CommServe. See Activate Licenses for step-by-step instructions.
  6. Export the data associated with the affected clients from the standby CommServe as described in Export Data from the Source CommCell.

    When you start the Command Line Interface to capture data, use the name of the standby CommServe in the -commcell argument.

  7. Import the exported data to the main CommServe as described in Import Data on the Destination CommCell.

    This brings back the entity in the CommServe database and the entity is visible in the CommCell Browser. (Press F5 to refresh the CommCell Browser if the entity is not displayed after a successful merge.)

  8. You can now browse and restore the data from the appropriate entity.

    As a precaution, mark media (tape media) associated with the source CommCell as READ ONLY before performing a data recovery operation in the destination CommCell.