Troubleshooting - VMware Restore

The following section provides information on some of the troubleshooting scenarios related to restore:

Restore Failure

Restoring Independent Disk/Physical RDM results in VM not powering on

Problem

If the virtual machine under backup includes independent disks/physical RDMs, these disks will be skipped. During a full restore the independent disk/Physical RDM also gets restored with 0MB, and the virtual machine cannot be powered on.

Solution

Prior to restore, manually delete the independent disks/Physical RDMs and then power on the virtual machine.

File-Level Restores Introduce a Different File Size and Checksum

Problem

If a file-level restore is performed from a backup that used VCB mounter, the restored files may have a different size and a checksum.

Solution

1. From the Backup Set Properties dialog box, switch the backup mode to vStorage.
2. Re-run the backup.
3. Restore the files again.

SAN mode restores may be slower than NBD transport mode

Problem

When attempting restoration of a VMware virtual machine from disk backup in SAN environments, the restore job slows down with the events in VMware client GUI displaying “clear lazy zero”. This results in the performance of restores with SAN transport mode to be slower than in NBD transport mode.

Solution

While Restoring VM as Template, Registering Template VM Fails

Problem

When attempting restoration of a VMware virtual machine as a Template virtual machine, registering the Template virtual machine might fail.

Solution

Manually register the template virtual machine if the host is present under the folder.

Recovering Data Associated with Deleted Clients and Storage Policies

The following procedure describes the steps involved in recovering 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 which 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 which 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 will be used temporarily to build a CommServe.

Recovering Deleted Data

1. Locate the latest Disaster Recovery Backup which contains the information on the entity (Storage Policy, Client, Agent, Backup Set or Instance) that you are trying to restore.
   • You can 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.

2. On a standby computer, install the CommServe software. For more information on installing the CommServe, see CommServe Deployment.
3. Restore the CommServe database using the CommServe Disaster Recovery Tool from the Disaster Recovery Backup described in Step 1. (See Restore a Disaster Recovery Backup for step-by-step instructions.)
4. Verify and ensure that the Bull Calypso Client Event Manager Bull Calypso 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 will bring back the entity in the CommServe database and the entity will now be visible in the CommCell Browser. (Press F5 to refresh the CommCell Browser if the entity is not displayed after a successful merge.)

8. If you have additional data that was backed up after the disaster recovery backup and before the deletion of the entity, use the procedure described in Import Metadata from a Tape or Optical Media to obtain the necessary information.
9. You can now browse and restore the data from the appropriate entity.

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

Restores from snap fails in case of read-only disks in SAN mode

In case of restores for SAN storage with any vendor type, you need to assign write permission to the disk on the Virtual Server proxy.

For Example:

If disk 12 is the disk you are trying to restore:

Z:\Henry\vmware>diskpart

select disk 12

DISKPART> disk attributes

attributes disk clear readonly

Revert Operation in Pending State

symptom

The Revert job may go to Pending state with the following error:

File level revert is not supported for a Virtual Machine [%VMNAME%] which is on VMFS datastore. [Datastore(s) [%DatastoreName%] does not support file level revert.

Cause

The virtual machine may have NFS and iSCSI disks. Ensure that all the disks reside on the NFS data store. If the data does not reside on the NFS data store, you cannot perform the revert operation.

Solution

Perform the conventional Container Restore to bring the data back to the point-in-time.

Revert Operation Fails

Before starting the revert operation, ensure that the Snapshot which you are using to perform the revert operation is not mounted.

File level restore fails

Symptom

While restoring files and folders from a virtual machine, you may get following error:

Volume name not found in the restore source path <source_path>, this is a volume restore.

Cause

This error appears when you have selected all files and folders in a virtual machine for the restore.

The file level restore of entire contents of the VM is not supported.

Solution

If you want to restore entire contents of a VM, perform a full VM restore.

Virtual Machine is restored successfully but not added to the correct resource pool

Symptom

The virtual machine is not added to the correct resource pool after the restore.

Cause

This error appears in the following scenarios:

• You have performed the backup of the virtual machine using an ESX Server and the ESX Server is managed by a vCenter.
• You are restoring virtual machine to an ESX Server and the ESX Server is managed by a vCenter.

Solution

If the ESX Server is managed by the a vCenter, do not configure the instance for the ESX server. Configure an instance for the vCenter and then perform the backup.

Similarly, before performing the restore, ensure that the instance is configured for the vCenter and not for the ESX server.  

Virtual machine client names are getting created with '_1' appended to the original client name

Symptom

When viewing virtual machines in the Client Computers list, you may see duplicated client names (for example, <ClientName> and <ClientName>_1).

Cause

Virtual machine information is added to the database during the discovery phase of a backup. If information changes, a new client is discovered during the discovery phase.

Making changes to information such as the virtual machine fully qualified domain name (FQDN), the GUID, or the host name can cause this issue.

Resolution

To avoid duplicate client entries caused by different client or host name:

Use the install software option for the client level in the CommCell Console (rather than interactively installing software to the virtual machine Guest Operating System).

To correct existing clients:

If duplicate clients are created with '_1" appended to the original client name, you can perform the following steps to merge the duplicate client back into the original: 

1. At a command prompt, navigate to the software installation path, log in to the CommServer, and run the following script:

   qoperation execscript -sn QS_SetVMClient -si @sourceClient='<ClientName>_1' -si @destClient='<ClientName>'

   where <ClientName> is the original client name and <ClientName>_1 is the duplicate.

   This script reassigns all backup history from <ClientName>_1 to <ClientName>. This enables you to view backup history, and to generate Job Summary Reports with the Include Protected VMs option enabled.

2. Remove the duplicate clients:
   1. In the CommCell Console, go to Control Panel | User Preferences.
   2. Click the Client Computer Filter tab.
   3. Select the Show Virtual Server Discovered Clients option.
   4. Delete the duplicate clients from the CommCell Browser.

Failed to start the virtual machine

Symptom

When a virtual machine has been replicated in vSphere and backed up, and a full VM restore is performed from the backup, the following status message might be displayed in vCenter:

Failed to start the virtual machine.

Cause

If the Power ON Virtual Machine After Restore option is selected when performing a full VM restore, VMware attempts to power on the restored VM before disabling replication.

Resolution

Clear the Power ON Virtual Machine After Restore option when initiating the restore. VMware automatically disables replication when the restore is completed, and you can power on the virtual machine manually.

Cannot restore files from a Windows 2012 virtual machine using deduplication

Symptom

When restoring from a backup of a Windows 2012 virtual machine that has deduplication enabled, a file-level restore completes successfully but only creates stub files.

Cause

File-level restores are not supported for deduplicated volumes from a Windows 2012 VM.

Resolution

To retrieve files from a backup for a Windows 2012 VM using deduplication, restore the disk that contains the file.

Alternatively, you can install a local file system agent on the Windows 2012 VM to enable file-level restores.