Troubleshooting - SnapProtect for Microsoft Hyper-V
- SnapProtect backup for online virtual machines in Hyper-V clusters fails
- SnapProtect backups for some storage arrays may fail
- Backup fails when using third party hardware VSS provider: "VSS service or writers may be in a bad state."
- While performing a restore operation, the MediaAgent does not have access to the storage device
- File-level restore from Snap fails
- Virtual machines restored from SnapProtect are not powered on automatically
- File-level restore fails
- Virtual machines are not connected to the network after a restore
- Cannot restore files from a Windows 2012 virtual machine using deduplication
- Recovering data associated with deleted clients and storage policies
- Backup goes to Pending state with error: "Unable to find OS device(s) corresponding to clone(s)."
- Backup using NetApp cluster mode LUNs fails with error: "Snapshot operation not allowed due to clones backed by snapshots"
SS0014: SnapProtect backup for online virtual machines in Hyper-V clusters fails
You can resolve this issue by temporarily suspending the virtual machine during the SnapProtect operation.
SS0015: SnapProtect backups for some storage arrays may fail
You can resolve this issue by making sure that before running a backup, you need to have a proxy machine with a MediaAgent installed on it. Also, the proxy machine should have a small sized LUN provisioned from the same file server where the snapshots are created.
HPV0022: Backup fails when using third party hardware VSS provider: "VSS service or writers may be in a bad state."
When you have installed a hardware VSS provider provided by a storage vendor, SnapProtect backups fail with the following error:
Error Code: [91:8]
Description: Unable to snap virtual machine [<VM_Name>]. VSS service or writers may be in a bad state. Please check vsbkp.log and Windows Event Viewer for VSS related messages. Or run 'vssadmin list writers' from command prompt to check state of the VSS writers; if the 'Microsoft Hyper-V VSS Writer' reports an error, please restart the 'Virtual Machine Management Service' (vmms.exe).
The filer's hardware VSS provider might not be able to create a shadow copy for the snapshot.
Configure the VSSProvider additional setting to use the software VSS provider from Microsoft:
- To find the ID, run the following command on the client computer:
vssadmin list providers
- Copy the provider ID for the software VSS provider from Microsoft.
An example of a provider ID is 400a2ff4-5eb1-44b0-8a05-1fcac0bcf9ff.
- From the CommCell Browser, navigate to Client Computers.
- Right-click the client and select Properties.
- Click Advanced, then click the Additional Settings tab.
- Click Add.
- On the Add Additional Settings dialog box, provide the following information:
- Name: Type VSSProvider.
- The Category field is automatically set to VirtualServer and the Type field is set to STRING.
- In the Value file, enter the VSS Provider ID for Microsoft.
- Click OK to save additional settings, advanced settings, and client properties.
Your backup operations will use the VSS Provider from Microsoft.
SS0016: While performing a restore operation, the MediaAgent does not have access to the storage device
If the storage policy uses a MediaAgent that does not have access to the storage device where the snapshot was created, additional steps are required while selecting the options in the Restore Options for all selected items window.
- Click on the Advanced button.
- From the Advanced Restore Options window, click the Data Path tab.
- Select a proxy from the Use Proxy dropdown to mount the snapshot.
- Click OK.
SS0017: File-level restore from Snap fails
The restore operation fails when you are restoring files or folders from a snapshot.
The restore fails if the Hyper-V role is not enabled in the MediaAgent computer.
In this scenario, you can use following procedure to restore files and folders from a disk level backup:
- Enable Hyper-V role on the MediaAgent computer and perform the restore operation.
- Using advanced browse option, select another MediaAgent computer with Hyper-V role enabled on it. It could possibly be the computer where the snap backups were performed or the destination computer specified during the restore where the MediaAgent is available with the Hyper-V role enabled.
SS0018: Virtual machines restored from SnapProtect are not powered on automatically
The virtual machine might have been in a running state during the SnapProtect backup. Consequently, the virtual machine is restored in a saved state.
To resolve this issue:
- Right-click the virtual machine in the Hyper-V Manager.
- Click Delete Saved State.
SS0019: File-level restore fails
The restore operation fails when you are restoring files or folders from a Disk Level backup.
The restore fails if the Enable Granular Recovery option is not selected before performing the backup or the Granular Recovery operation fails.
In such scenario, you can use following procedure to restore files and folders from a disk level backup:
- Mount the snapshot that contains the data which you want to restore. For more information, refer to Mount Snapshots.
- Browse the Destination Path which you selected while mounting the snapshot and locate the VHD file for the disk which contains the required files and folder.
- Use the DiskManager to mount the VHD file on any Windows server. A new drive will be created on the Windows server.
- Browse the files and folder on this drive and copy the required files and folders to a desired destination.
HPV0011: Virtual machines are not connected to the network after a restore
When a Hyper-V virtual machine is restored to a different Hyper-V host (an out-of-place restore), the restored virtual machine has no network device. NICs are not automatically restored with the corresponding virtual machine.
When a virtual machine is restored to a destination host that does not have the same names for virtual switches as the source host, the network adapter is not restored. The network connection is restored only if the same connection is available on the destination host at the time of the restore.
To resolve this issue, use either of the following approaches:
- Before running an out-of-place restore, create a virtual switch on the destination host with a name that matches the virtual switch on the source Hyper-V host. Only use this approach if it is appropriate to use the same network connection for the virtual machine on the new host.
- After the virtual machine is restored, manually connect the network adapter to a different virtual switch on the destination host.
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.
Windows 2012 provides its own native deduplication capability. If a Windows 2012 VM has native deduplication enabled, file-level restores from backups are not supported because the backed up files are only stored as stubs.
Use one of the following methods to restore files:
- To retrieve files from a backup for a Windows 2012 VM using deduplication, use the Virtual Machine files option on the Restore Options dialog to restore the virtual machine disk that contains the files.
- Install a local file system agent on the Windows 2012 VM to enable file-level backups. As a result, the data is backed up in a rehydrated state so that you can restore file-level data from that backup.
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
- 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.
- On a standby computer, install the CommServe software. For more information on installing the CommServe, see Install the CommServe.
- 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.)
- Verify and ensure that the NetApp Client Event Manager NetApp Communications Service (EvMgrS) is running.
- 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.
- 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.
- 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.)
- 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.
HPV0025: Backup goes to Pending state with error: "Unable to find OS device(s) corresponding to clone(s)."
When performing an SnapProtect backup, the job goes pending and the following error message is displayed:
Error Code: [32:392] Unable to find OS device(s) corresponding to clone(s). Possible reasons could be 1) Improper FC/iSCSI H/W connection between the host and the array 2) The OS didn't find the device corresponding to the clone. : [Unable to find OS device(s) corresponding to snap(s)/clone(s)]
If a Fibre Channel (FC) adapter is found on a Windows or UNIX client, FC is used by default when attempting to mount snapshots. If the array host is configured to use iSCSI and the storage array is not configured with an FC port, the storage array may still create FC host groups even though FC connectivity is not available.
To use iSCSI even when a Fibre Channel adapter is detected, set the sSNAP_IsISCSI additional setting to Y for the Virtual Server Agent. This setting forces iSCSI usage, enabling device discovery to succeed.
HPV0026: Backup using NetApp cluster mode LUNs fails with error: "Snapshot operation not allowed due to clones backed by snapshots"
When performing an SnapProtect backup for a Microsoft Hyper-V virtual machine using NetApp cluster mode LUNs, the backup fails with the following error:
The provider was unable to perform the request at this time. The job will go to pending state and will be retried.
The cvma.log file contains the following error message:
Snapshot operation not allowed due to clones backed by snapshots.
This failure happens during a clone operation, typically of a large LUN. The backup attempt cannot continue until the clone operation is completed, and must be retried after an appropriate interval (for example, 60 seconds).
You can configure additional settings to set the number of times the backup operation is retried (snapshot retry count) and the time interval in seconds between retries (snapshot retry interval).
Use the nONTAPSnapCreationRetryCount additional setting to increase the snapshot retry count to 30.
Use the nONTAPSnapCreationRetryIntervalInSecs additional setting to increase the snapshot retry interval to 60.