VMware

VMware Data Recovery 1.1 Release Notes

Features | Documentation | Knowledge Base | Communities

Data Recovery | 04 Nov 2009 | Build 207380

Last Document Update: 19 NOV 2009

Check frequently for additions and updates to these release notes.

Benefits and Features

Read about the benefits and features of this product at VMware Data Recovery Overview - VMware. For additional information about known issues and resolved issues, see:

Supported Environments

VMware Data Recovery 1.1 can be used with:

  • VMware vSphere 4.0
  • VMware vSphere 4.0 Update 1

Upgrading to Data Recovery 1.1

Previous Data Recovery installations are likely to have existing restore points that should be preserved. To ensure these restore points are preserved, it is important to use the following processes described in this section.

Begin the upgrade process by installing the latest Data Recovery plug-in for the vSphere client.

To install the latest Data Recovery plug-in

  1. Close the vSphere Client.
  2. Use the Add or Remove Programs item in the Control Panel to uninstall any previous versions of the Data Recovery plug-in.
  3. Start the latest Data Recovery plug-in Windows Installer File (.msi) to install the Data Recovery plug-in.

Next you must deploy the new Data Recovery appliance without deleting existing restore points. If the destination volume for the deduplication store is a virtual disk, do not to delete the appliance. Deleting the appliance deletes the disks connected to the appliance. This would cause the backup data stored in the deduplication store to be deleted. To avoid such an issue, complete the following procedure:

To upgrade Data Recovery appliances with virtual disks

  1. Check if any backup jobs are currently running. When no jobs are running, shut down the Data Recovery appliance.
  2. If you want to save the original Data Recovery appliance, rename it in some way. For example, you might rename an appliance called VMware Data Recovery to VMware Data Recovery - OLD.
  3. Deploy the new appliance.
  4. Use the datastore browser to move the disk containing the deduplication store to the same location as the new appliance.
  5. Edit the settings of the new appliance:
    1. Choose a Add > Hard Disk.
    2. Choose Use an Existing Virtual Disk
    3. Browse to the data store and select the virtual disk which is connected to the older appliance as destination.
    4. Choose the SCSI address.
    5. Choose Finish.
  6. Power on the new appliance.
  7. Edit the settings of the older appliance:
    1. Choose the hard disk which is used to store deduplication store.
    2. Select Remove, leave default option for remove from virtual machine. DO NOT select remove from virtual machine and delete files from the disk.
    3. Click OK.
  8. Configure networking on the new appliance.
  9. Use the Data Recovery vSphere plug-in to connect to the backup appliance.
  10. Complete the getting started wizard. Note that you should mount the desired disk, but do not format it. Formatting the disk will erase all deduplication store data. The disk to be used may not display the expected name, but the proper name will be displayed after the wizard is completed.
  11. You are prompted to restore the configuration from the deduplication store. Select Yes if you want to restore the jobs and backup events and history.
  12. The client disconnects from the appliance after the configuration is restored and then reestablishes the connection. This may take several minutes.
  13. Verify the backup job configuration.
  14. Remove the older VMware Data Recovery appliance from the inventory.

Note that corrupt restore points may cause the upgrade to fail. If you receive the message "Could not restore the Data Recovery appliance configuration" re-add the destination to the original Data Recovery appliance and then run an integrity check to clean up any corrupt restore points. After the integrity check completes successfully, repeat the upgrade process.

If the destination volumes for the deduplication store is a CIFS share or an RDM, complete the following procedure:

To upgrade Data Recovery appliances with CIFS shares or RDMs

  1. Check if any backup jobs are currently running. When no jobs are running, shut down the Data Recovery appliance.
  2. If you want to save the original Data Recovery appliance, rename it in some way. For example, you might rename an appliance called VMware Data Recovery to VMware Data Recovery - OLD.
  3. Delete the older Data Recovery appliance.
  4. Deploy the new appliance.
  5. Edit the settings of the new appliance:
    1. Choose a Add > Hard Disk.
    2. Choose the option to add a RDM and then select the LUN that contains the deduplication store.
    3. Browse to the data store and select the virtual disk which is connected to the older appliance as destination.
    4. Choose the SCSI address.
    5. Choose Finish.
  6. Power on the new appliance.
  7. Configure networking on the new appliance.
  8. Use the Data Recovery vSphere plug-in to connect to the backup appliance.
  9. Complete the getting started wizard. Note that you should mount the desired disk, but do not format it. Formatting the disk will erase all deduplication store data. The disk to be used may not display the expected name, but the proper name will be displayed after the wizard is completed.
  10. Mount the CIFS share in the appliance.
  11. You are prompted to restore the configuration from the deduplication store. Select Yes if you want to restore the jobs and backup events and history.
  12. The client disconnects from the appliance after the configuration is restored and then reestablishes the connection. This may take several minutes.
  13. Verify the backup job configuration.
  14. Remove the older VMware Data Recovery appliance from the inventory.

Note that corrupt restore points may cause the upgrade to fail. If you receive the message "Could not restore the Data Recovery appliance configuration" re-add the destination to the original Data Recovery appliance and then run an integrity check to clean up any corrupt restore points. After the integrity check completes successfully, repeat the upgrade process.

Enhancements

The enhancements have been made for this release of Data Recovery.

  • File Level Restore Functionality is Officially Supported

    File Level Restore (FLR) provides a way to access individual files within restore points for Windows virtual machines. In previous versions of Data Recovery, FLR was provided as an experimental feature. File Level Restore feature is now officially supported.

  • Integrity Check Stability and Performance Improved

    The integrity check process is faster and more stable. Note that integrity checks are computationally intensive processes and can take significant periods of time. The exact amount of time integrity checks take varies based on of the size of the deduplication store. Even with these enhancements, integrity checks that take several hours are not unexpected.

  • Integrity Checks Provides Improved Progress Information

    When an integrity check is running, a progress indicator is displayed. This progress indicator has been improved, although it does not provide the optimal level of detail.

  • Enhanced CIFS Shares Support

Resolved Issues

The following issues have been resolved since the last release of Data Recovery. The list of resolved issues below pertains to this release of Data Recovery only.

  • Termination of Incomplete Backup Jobs Produce Errors

    Backup jobs are only permitted to run during the backup window. If a backup job was in progress when the time period for the backup window ends, the backup job was terminated, and the following error was logged: Script execution terminated at specified stop time. When a backup job only partially completed, the resulting incomplete restore point could produce the following integrity check error: Backup Set format inconsistency (10 at n), where n is a variable number. Data Recovery has been modified so this issue does not occur.

  • Restore Wizard Does not Enforce Valid Datastore Selections

    Using the restore wizard, it was possible to specify datastore locations to which to restore virtual machines where the datastore was not valid. For example, when:

    • A datastore was renamed or deleted, the old information persisted, so an outdated name or non-existent store could be selected.
    • A virtual machine was to be restored to a cluster, datastores that were not on shared storage could be selected.

    Wizards have been modified so only valid selections are offered.

  • Restoring Virtual Disks Never Powers on a Virtual Machine

    It is possible to restore a backed up virtual disk, while not restoring the virtual machine on which the disk is installed, leaving the virtual machine in its present state. The restore process includes an option to power on the virtual machine whose disk is restored. If only the disk was restored, but not the virtual machine, the virtual machine was not powered on, regardless of the configured settings. Data Recovery has been modified so after restoring a disk, virtual machines are now powered on if configured to do so.

  • Restore Points May not Be Displayed in the vSphere Client

    In rare cases, the Restore tab did not show any restore points, even though valid restore points existed. The Restore tab now shows all available restore points.

  • Removed Hosts and Clusters not Updated in vSphere Client as Expected

    Data Recovery displays available hosts and clusters in the vSphere Client user interface. If a host or cluster was removed from vSphere, renamed, and re-added to vSphere, both the new and old instances were displayed in the Data Recovery plug-in. Hosts and clusters are now displayed properly, although there may be a delay before the most recent information is displayed.

  • Users Are Asked For Credentials Multiple Times During Backup Appliance Setup

    Users were asked for a username and password for a vCenter administrator account twice when first deploying the backup appliance. When first connecting to the appliance, the credentials were required to authenticate to vCenter, and the Getting Started wizard also requested vCenter credentials for use during backups. This no longer occurs.

  • Network Destinations Must Be specified Using IP Addresses

    Using DNS-resolved names to specify network destinations was not supported with Data Recovery. Data Recovery now supports adding network destinations using DNS-resolved names of the format \\example\share, as well as \\192.0.2.12\share.

  • Deleted Virtual Machines May not Restore to Expected Folder Location

    A virtual machine can be deleted from the inventory and then restored using Data Recovery. If a virtual machine was in a folder in the VMs and Templates view, the virtual machine was restored to the root level of the ESX server for that view. Virtual machines are now restored to their original locations.

Known Issues

The following known issue has been discovered through rigorous testing. The list of issues below pertains to this release of Data Recovery only.

  • ESX Servers May List Datastores Multiple Times

    When restoring virtual machines to ESX servers, the restore location in the restore wizard may show the same datastore name multiple times. ESX servers can be configured to use shared storage and local storage. It is possible for multiple servers to use the same shared storage and it is possible for the local storage names to be similar among servers. For example, multiple servers could point to "SharedStorage1" and multiple servers could each have local storage called "DataStore1". This is especially problematic if users select locations for disk files and configuration files that are on separate servers, producing an invalid configuration. The potential for misconfiguration is not initially evident based on storage destination names, but an error identifies such an issue. If such an error occurs, select different combinations of storage destinations until an appropriate pair is found.

  • File Level Restore Indicates Some Registry Data May Have Been Lost

    Data Recovery can create restore points for misconfigured virtual machines. File Level Restore can mount such restore points, but doing so may result in the display of registry error messages. The error may appear as follows: Registry hive (file): C:\DOCUME~1\ADMINI~1\LOCALS~1|Temps\Administrator\vixmntapi3 was corrupted and it has been recovered. Some data might have been lost. These errors can be safely ignored.

  • Windows Server 2008 Virtual Machine Backups May Fail If Disk UUIDs Are Enabled

    Data Recovery can only back up a Windows Server 2008 virtual machine if it does not have disk.EnableUUID=TRUE in its VMX file. This entry only appears in for Windows Server 2008 virtual machines that were created in vSphere 4.1. Before backing up such virtual machines, power off the virtual machine, and then remove the disk.EnableUUID=TRUE entry from the VMX file. After removing this entry, the virtual machine backs up as expected.

  • CIFS Share Names with Non-ASCII Characters Cannot Be Mounted

    The backup appliance can use CIFS shares for storing restore points. If a CIFS share has non-ASCII characters, attempts to mount that CIFS share fail. To resolve this issue, use CIFS shares with names that use only ASCII characters.

  • Data Recovery Does not Support CIFS Shares with Blank Passwords

    The backup appliance can use CIFS shares for storing restore points. If a CIFS share has a blank password, the CIFS share is unusable. To resolve this issue, use CIFS shares that are password protected.