VMware

VMware Data Recovery 2.0 Release Notes

VMware Data Recovery 2.0 | Build 433157

Last Document Update: 28 Nov 2011

Check frequently for additions and updates to these release notes.

These release notes include the following topics:

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

For information on supported environments, see the VMware Compatability Guide.

Upgrading to Data Recovery 2.0

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 VMware 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 or RDMs

  1. IMPORTANT: Before upgrading to VMware Data Recovery 2.0, make sure all operations in your current environment have completed before shutting down and performing the upgrade. If an integrity check or reclaim operation is running, allow the operation to complete. Do not CANCEL these operations.
  2. When no operations are running, unmount the destination disk and shut down the Data Recovery appliance.
  3. 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.
  4. Deploy the new appliance.
  5. Use the datastore browser to move the disk containing the deduplication store to the same location as the new appliance.
  6. 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.
  7. Power on the new appliance.
  8. 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.
  9. Configure networking on the new appliance.
  10. Use the Data Recovery vSphere plug-in to connect to the backup appliance.
  11. 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.
  12. 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.
  13. The client disconnects from the appliance after the configuration is restored and then reestablishes the connection. This may take several minutes.
  14. Once the client reconnects, check to see if a Reclaim or Integrity check operation has started. If so, STOP the operation.
  15. Immediately click Configure > Destinations and perform an integrity check on all mounted destinations.
  16. Verify the backup job configuration.
  17. Remove the older VMware Data Recovery appliance from the inventory.

Note that damaged 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 damaged 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

  1. IMPORTANT: Before upgrading to VMware Data Recovery 2.0, make sure all operations in your current environment have completed before shutting down and performing the upgrade. If an integrity check or reclaim operation is running, allow the operation to complete. Do not CANCEL these operations.
  2. When no operations are running, unmount the destination disk and shut down the Data Recovery appliance.
  3. 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.
  4. Delete the older Data Recovery appliance.
  5. Deploy the new appliance.
  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. On the Backup Destination page, click the Add Network Share link and enter the appropriate information for your particular CIFS share.
  10. 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.
  11. The client disconnects from the appliance after the configuration is restored and then reestablishes the connection. This may take several minutes.
  12. Once the client reconnects, check to see if a Reclaim or Integrity check operation has started. If so, STOP the operation.
  13. Immediately click Configure > Destinations and perform an integrity check on all mounted destinations.
  14. Verify the backup job configuration.
  15. Remove the older VMware Data Recovery appliance from the inventory.

Note that damaged 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 damaged restore points. After the integrity check completes successfully, repeat the upgrade process.

Enhancements

VMware Data Recovery 2.0 includes many enhancements. For details about using new features, refer to the VMware Data Recovery Administrator's Guide. Some of the enhancements that have been made for this release of Data Recovery include:

  • The Data Recovery appliance uses CentOS 5.5 64-bit as its operating system. This change provides better scalability and stability for the appliance.
  • Swap files are no longer included in backups. Since swap files are not relevant to restoring virtual machine systems, these are omitted, allowing backups to complete more quickly and to consume less disk space.
  • Integrity checks and reclaim operations are schedulable using the Destination Maintenance window.
  • Integrity checks are more flexible.
    • The progress is tracked. If Data Recovery stops an integrity check, the check can be resumed without having to restart the entire process. For example, a check might be stopped because the timeframe for the maintenance window has passed. Note that if a user manually stops an integrity check, when an integrity check is started again, it begins at the start.
    • Other operations can be completed while an integrity check is running. For example, backup and restore tasks can be completed while an integrity check is running.
  • The performance of backup, integrity check, and reclaim operations has been improved.
  • Data Recovery is more resilient against transient network failures. For example, backups to CIFS shares perform better even when subject to transient network failures.
  • The backup appliance may be suspended from starting new backup jobs.
  • Email reporting is included.

Known Issues

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

  • FLR Fails To Mount Virtual Machines With Upgraded Hardward Versions

    When FLR is used to access a virtual machine, drivers are installed on the physical virtual machine that is accessing the virtual machine. The installed drivers correspond to virtual hardware versions. If virtual machines are upgraded from virtual hardware version 4 to virtual hardware version 7, the virtual machine can no longer be accessed because the drivers are out of date. To resolve this issue, the old drivers must be removed and new ones installed. For more information on virtual hardware versions, see KB 1003746.

  • Email Reports Format Improperly

    In some cases, multiple sections of the email report may be displayed on a single line of text, which may be difficult to read. This typically occurs in Microsoft Outlook. To resolve this issue, use method 1 described in Microsoft's KB 287816.

  • Multiple Email Reports Sent For Single Incidents

    In certain cases, Data Recovery sends multiple copies of email reports for single incidents. Ignore the duplicate notifications.

  • Previous Client Plug-In Versions Interpret Backup Appliances That Require SSL As Being Unresponsive

    By default, Data Recovery 2.0 requires SSL connections. Data Recovery 1.2.1 and earlier are not designed to use SSL. As a result, problems may occur if a 2.0 version of the backup appliance requires SSL, and a user is attempting to connect using an older version of the client plug-in. In such a case, the client plug-in interprets the failure to connect as indicating that the backup appliance is not running or is unresponsive. To resolve this issue, upgrade the client plug-in to the same version as the backup appliance, thereby enabling SSL support.

    Alternately, SSL can be disabled on the backup appliance by modifying settings in the datarecovery.ini file. ConnectionAcceptMode controls how Data Recovery connects over the network. The default ConnectionAcceptMode setting of 1 requires SSL. A setting of 2 requires plaintext. A setting of 3 tries SSL, but allows failback to plaintext.

  • Restore of Virtual Machine Fails When Connected Directly to ESXi Host

    Sometimes you must restore a virtual machine directly to an ESXi host, for example in disaster recovery when ESXi hosts the vCenter Server as a virtual machine. A new vSphere 5 feature tries to prevent this if the ESXi 5.0 host is managed by vCenter. To circumvent this and restore the virtual machine, you must first disassociate the host from vCenter. In earlier releases, vCenter management had less state but was revocable only from vCenter.

    1. Using the vSphere Client, connect directly to the ESXi 5.0 host.
    2. In the Inventory left-hand panel, select the host.
    3. In the right-hand panel, click Summary.
    4. There in the box titled Host Management, click Disassociate host from vCenter Server.
      It is not necessary to put the host in Maintenance Mode.
    5. Once the vCenter Server has been restored and is back in service, use it to reacquire the host.

  • If Using HotAdd Backup, Add SCSI Controllers to Linux Virtual Machines in Numeric Order

    Linux systems lack an interface to report which SCSI controller is assigned to which bus ID, so HotAdd assumes that the unique ID for a SCSI controller corresponds to its bus ID. This assumption could be false. For instance, if the first SCSI controller on a Linux VM is assigned to bus ID 0, but you add a SCSI controller and assign it to bus ID 3, HotAdd advanced transport mode may fail because it expects unique ID 1. To avoid problems, when adding SCSI controllers to a VM, the bus assignment for the controller must be the next available bus number in sequence. Also note that VMware implicitly adds a SCSI controller to a VM if a bus:disk assignment for a newly created virtual disk refers to a controller that does not yet exist. For instance, if disks 0:0 and 0:1 are already in place, adding disk 1:0 is acceptable, but adding disk 3:0 breaks the bus ID sequence, implicitly creating out-of-sequence SCSI controller 3. To avoid HotAdd problems, you should also add virtual disks in numeric sequence.

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.

  • Data Recovery Client Plug-In Failed to Connect To Appliance

    In cases where reverse DNS lookups were misconfigured, the vSphere Client plug-in would fail to connect as expected. The client has been modified to resolve this issue.

  • Deduplication Store Is Unusable With Generic I/O Error

    Data Recovery 2.0 Beta 1 was intentionally designed to not permit use with Data Recovery 1.2 and earlier deduplication stores. After attaching to a deduplication store that was created using Data Recovery 1.2 or earlier, attempts to restore, backup, or complete integrity checks all failed. Data Recovery 2.0 Beta 2 and later is designed to work with earlier deduplication stores, so this issue no longer exists.

  • Creating A Backup Fails With Error 1 Unknown

    Creating a backup with the current minimum creditials could fail with the error Snapshot fails with error 1 unknown. This was due to changes implemented for disabling vMotion during a backup. This issue has been resolved.

  • Linux Virtual Machines Require Swap Space Be Enabled After Restore

    Data Recovery did not back up swap partition for Linux virtual machines. When such a virtual machine is restored, the swap space was disabled. This issue has been resolved and the swap space is now restored as expected.

  • Clients May Fail To Connect After Connecting A Deduplication Store To A Different Appliance

    After running backups with a Data Recovery 2.0 Beta 1 backup appliance, if you removed the deduplication store destination and attached it to a new Data Recovery 2.0 Beta 1 backup appliance, the plug-in failed to reconnect after importing the configuration files. This issue has been resolved and the plug-in reconnects as expected.

  • Disk Becomes Full On vCenter Server On Linux

    When the Data Recovery backup appliance was installed on a vCenter Server on Linux, logs could quickly consume all available disk space. This issue has been resolved.

  • Web Management Interface Is Unavailable

    The web management interface was unavailable. During the Backup Appliance startup, error codes appeared related to the web management interface not starting as expected appeared. The web management interface can now be used as expected.

  • Solaris Disks May Be Excluded

    By default, Data Recovery 2.0 does not back up information stored in a virtual machine's swap partition or pagefile.sys file. Data Recovery identifies the swap space partition in Solaris by examining disk identifiers. Older versions of Solaris used the same identifier (0x82) to identify disks that is currently used by Linux to identify the swap partition. As a result, Data Recovery did not back up any disks with a 0x82 identifier, which may include non-swap space storage for Solaris disks. This issue has been resolved, and Solaris disks are now backed up as expected.