Frequently Asked Questions - Image Level iDataAgent

What happens during a file level restore?

File Level restores are carried out as extractions of content from the Image Level backup. The following sequence of events takes place during a File Level Restore:

1. During Browse, if the index is not available in the cache, a request is sent to the MediaAgent to index the objects selected for restore.

2. The Master File Table of the Backup is scanned to determine the number of blocks (extents) that contain the files to be restored.

3. The MediaAgent restores the selected files to the designated client and places them in the temporary directory.

4. The Restore process on the client extracts the file data from the restored extents and then restores files from them.

5. Once the restore operation is complete, it will clean up the temporary directory to which the extents were restored.

When a File Level restore is started, metadata is restored prior to the actual restore of files, and during this time, a message might indicate the Index Cache is being restored, although it already exists. Also, the media containing this metadata will be mounted into the library even if this media does not contain the data from the full backup.

What are the file systems and restore types supported on UNIX operating systems?

The following table lists the file systems and restore types supported for each supported operating system:

For a complete listing of applications supported for each operating system, see Image Level - Application Support.

What are the limitations for file level restores?

Consider the following before doing a file level restore:

• The Image Level on Unix iDataAgent can perform a File Level Restore only when the operating systems and their versions on the Client computer and the MediaAgent are same. If the operating systems of the Client computer and the MediaAgent are different, the File Level Restore job will go into pending state with the error message - Please check the log files for this job for more details.

• For a Windows MediaAgent, the Index Cache folder must reside on an NTFS partition.

• If metadata was not collected during a backup, a File Level restore cannot be performed. This might result from having selected the Skip Metafile Creation option in the Advanced Backup Options screen, or as a result of failure to collect metadata during the backup, in which case the system generated an Event Message warning of the failure.

• Do not restore:

  • hidden objects

  • system files

  • recycler files

• Image Browse is not supported. A no-image browse operation returns the most recent version of the data that existed back to the most recent full backup, rather than returning an image of the specified entity (i.e., file system/directory). To perform a File Level Restore of an entity to a point in time, you will need to Browse back in time, to the point in time you want to restore.

• If the cluster size (allocation unit) on the disk that you backed up was less than 1024 bytes, a file level restore job will not complete successfully.

What are the limitations for volume level restores?

Consider the following before doing a volume level restore:

• Since Image Level restores a portion of Volume Information to the MediaAgent Index Cache, if encryption was enabled when the data was backed up, the Volume Information will be encrypted as well. This requires a Pass-Phrase on the MediaAgent to decrypt during the restore. There are two ways to handle this:

  • Export an Encryption Pass-Phrase to the MediaAgent in use as well as the destination Client (if using Alternate Data Paths (GridStor), it needs to be exported to all the MediaAgents.)

• Although you can use the Image Level iDataAgent to back up volumes of a clustered shared disk, you cannot use the Image Level iDataAgent to restore directly to the volumes of a clustered shared disk.

• For a Volume Level Restore from a Unix Checksum backup, volume detection must be run from Volume Explorer prior to the restore. The Restore Options dialog box will display the list of volumes available for the restore.

• The Windows 2000 and higher operating systems allow you to add new volumes to the existing file system name space without using new drive letters. For each volume that you add in this manner, Windows establishes a mount point, a pointer from the directory to the target data. Mount points are supported subclient content.

• For the Windows Image Level iDataAgent, you can add volumes to existing subclient content or remove them. However, whenever volumes are added or removed, the next backup job will be converted to a full backup.

• For Solaris, if the slice 0 partition is empty and the disk is allocated space from slice 1 onwards, then slice 1 will be considered as slice 0 by the agent. So, from whatever slice partition you start to allocate space on the disk, that particular slice will be considered as slice 0.

• The size of a volume defined as subclient content will not be displayed until after the first backup and a refresh the CommCell Browser view.

Can we use the Image Level iDataAgent to back up and restore operating system volumes for disaster recovery scenarios?

No. Image Level iDataAgent cannot be used for disaster recovery of operating system volumes.

How do we estimate the required free space for extent recovery location?

The amount of free space needed for the extent recovery location is roughly the amount of files selected in the browse plus a percentage of overhead. Overhead estimation is dependent on the amount of fragmentation associated with the volume as originally protected via the Image Level backup.

Example1: If the default extent size is 1MB, in order to restore a 4KB file, a 1 MB extent is restored on the client to allow for the extraction of the 4KB file.

Example 2: A 400KB file is highly fragmented and scattered in 100 different extents. All 100 extents (100MB) will need to be restored to the machine to restore the 400KB file.