vSphere Data Protection (VDP) 6.0.1 Release Notes 19 MAY 2015

These release notes include the following topics:

Sep 25, 2012  vSphere Data protection – a quick guide how to do a VDP install, deploy and use. VSphere Data Protection is a new backup product, which does not bring an additional cost, but it's included in vSphere Essentials Plus and higher VMware vSphere package. The product is based on EMC's Avamar code and present an interesting upgrade for existing customers which are upgrading from vSphere. Jul 19, 2015  Few days ago wrote blog about how to Back up and Restore the vCenter Server 6.0 embedded vPostgres database. I am extending same topic and will discuss here how to Back Up and Restore vCenter Server using vSphere Data Protection.

Benefits and Features

Read about the benefits and features of this product at the following links:

Supported Environments

For information on supported environments, see the VMware Interoperability Matrix.

Known Issues in VDP 6.0.1

The following known issues have been discovered through rigorous testing. The issues pertain to vSphere Data Protection (VDP) 6.0.1.

Vsphere Data Protection 6.0

VMware Issues

  • Image backup fails for powered-on virtual machine running on VSAN datastore (1281041)

    An image backup fails for powered-on virtual machines running on a VSAN datastore, where both the VDP Appliance and the virtual machine are running on the same VSAN datastore, but are hosted and powered on by different vSphere hosts. The issue exists only when the virtual machine is in a Powered On state.

  • Support for routed / NAT / Firewall / IDS / TSNR between the VDP Appliance and the vCenter (1292848)

    When configuring the network for the VDP Appliance and the vCenter, modifying network address information using NAT or other configuration methods (for example: firewall, IDS, or TSNR) is not supported. When those tools are deployed as part of the virtual network, some VDP functionality may not work as designed.

  • Running in secure mode results in users not able to clean up previous failed backups, in which artifacts are left behind (1294581)

    Bugs 1293852 and 1294581 are related to enabling the secure mode. Currently in the VDP Appliance UI, we recommend that if users want to secure their deployment, they should run with the SSL host verification enabled (which is disabled by default). Previously this option did not exist.

  • With 5.8, root login was disabled (1309755)

    With 5.8, root login was disabled, as it is not a best practice. An option is needed to enable ssh root login. Additionally, the shell is set to time out after 15 minutes, if no activity occurs in the shell. An option is needed to disable the shell timeout. These improvements will help with the customer support experience during troubleshooting and while using the shell.

    Workaround:

    Log in by using the admin account. Then, use the sudo command to perform root functions.

    The bash shell (in the /etc/profile directory) is set for a 15-minute timeout if no activity occurs in the shell. You can add the console timeout value using the hardening script. For example:

    TMOUT=900

    export TMOUT

Documentation Issues

  • The SQL Server 2005 section in the 'VDP Application Support' chapter of the vSphere Data Protection Guide (versions 5.8 and 6.0) erroneously claims 'x64' support

    The text currently reads as follows:

    SQL Server 2005 SP3 x64 on:

    • Windows Server 2003 SP1 or later, x86/x64

    • Windows Server 2003 R2, SP2 or later, x86/x64

    • Windows Server 2008 SP1 or later, x86/x64

    • Windows Server 2008 R2, x64

    Note the SQL Server should read: 'SQL Server 2005 SP3' (remove 'x64'). The bullet points are correct.

  • Powering On of VM fails when backed up VM was connected to DVS and restored to other ESX (222475)

    When powering on a VM after you restore it, vCenter returns a PowerOnFailure error similar to the following:

    DRS cannot find a host to power on or migrate the virtual machine. Network interface 'Network adapter 1' uses network '77 d3 02 50 5f 76 ca d7-db f9 42 6c 0f 6f 87 1f', which is not accessible

    This error message occurs when the environment where you restore the VM does not have the network connection that was present when you backed up the VM. For instance, a user backs up a VM that is connected to a distributed vSwitch. Then the user restores the VM to an ESX host that is part of a Distributed Resource Scheduler (DRS) cluster. The vSwitch does not exist in the DRS cluster. Powering on the VM, therefore, fails.

    Workaround:

    Edit the VM settings, set the network connection to the network adaptor, and then power on the VM.

  • VMware Proxies Appliance are vulnerable to a man-in-the-middle-attack (222547)

    By default, proxies do not validate SSL certificates when connecting to the vCenter Server. This can leave the vCenter Server vulnerable to a man-in-the-middle exploitation, which might result in unauthorized access to the vCenter Server. Configure each proxy to use an SSL certificate authentication when connecting to the vCenter Server to correct this vulnerability.

    Because of bug 222547, the 'Secure External Proxy Communication with vCenter' on pages 53-54 in the vSphere Data Protection 6.0 Administration Guide requires updates. The following procedure includes these updates. Use this procedure instead of the one on pages 53-54:

    1. Open a command shell and log in to the proxy as root.
    2. Copy the vCenter Server certificate to /usr/local/avamarclient/bin on the proxy:
      • For Linux vCenter Appliance:

        scp file /etc/vmware-vpx/ssl/rui.crt and /etc/vmware-vpx/ssl/rui-ca-cert.pem from vCenter appliance into /usr/local/avamarclient/bin on the proxy

      • For Windows vCenter:

        scp c:ProgramDataVMwareVMware VirtualCenterSSLrui.crt and c:ProgramDataVMwareVMware VirtualCenterSSLcacert.pem into /usr/local/avamarclient/bin on the proxy.

        NOTE: If a chained SSL certificate is used for the vCenter, copy the chain.pem file, which contains all certificates in the chain, to /usr/local/avamarclient/bin on the proxy.

    3. Set the proper operating system permissions on the certificate by typing:

      chmod 600 /usr/local/avamarclient/bin/rui.crt

      where rui.crt is the actual certificate name.

    4. Run the following command against the rui.crt to capture the SSL cert thumbprint:

      openssl x509 -in rui.crt -fingerprint grep Finger

      The output should look similar to the following:

      SHA1 Fingerprint=C7:35:19:95:9C:3F:56:1D:73:35:52:41:F3:02:46:A3:B9:46:4F:D9

    5. Open /usr/local/avamarclient/var/avvcbimageAll.cmd in a UNIX text editor.
    6. Append the following entries to the end of the file:

      --ssl_server_cert_thumbprint='thumbprint of rui.crt'
      --ssl_server_authentication_file=/usr/local/avamarclient/bin/rui-ca-cert.pem

      where rui.crt is the actual certificate name and thumbprint is the actual thumbprint for the vCenter Server. The output should look similar to the following:

      --ssl_server_cert_thumbprint='C7:35:19:95:9C:3F:56:1D:73:35:52:41:F3:02:46:A3:B9:46:4F:D9'

      NOTE: Use chain.pem for chained vCenter SSL certificates.

    7. Save your changes and close avvcbimageAll.cmd.
    8. Open /usr/local/avamarclient/var/avvmwfileAll.cmd in a UNIX text editor.
    9. Append the following entry to the end of the file:

      --ssl_server_authentication_file=/usr/local/avamarclient/bin/rui-ca-cert.pem

      where rui-ca-cert.pem is the actual certificate name.

      NOTE: Use chain.pem for chained vCenter SSL certificates.

    10. Save your changes and close avvmwfileAll.cmd.
    11. Open /etc/vmware/config in a UNIX text editor.
    12. Append the following lines to the end of the file:
      vix.enableSslCertificateCheck = 'true'

      vix.sslCertificateFile = '/usr/local/avamarclient/bin/rui-ca-cert.pem'
    13. Save your changes and close /etc/vmware/config.
    14. Open /usr/local/avamarclient/var/vddkconfig.ini in a UNIX text editor.
    15. Find the vixDiskLib.linuxSSL.verifyCertificates=0 entry.
    16. Change the vixDiskLib.linuxSSL.verifyCertificates=0 entry to 1:
      vixDiskLib.linuxSSL.verifyCertificates=1
    17. Save your changes and close vddkconfig.ini.
    18. Ensure that no backup or restore jobs are running on this proxy.
    19. Restart the avagent and vmwareflr services by typing the following commands:

      service avagent-vmware restart
      service vmwareflr restart

  • Service Stop/Start buttons become unavailable on Configuration page, when you run emwebapp.sh --restart from CLI (222670)

    Workaround:

    You must run emwebapp.sh from a sudo login shell (sudo -i) or as the root user (su - root). Otherwise, there is a chance that the services buttons on the Configuration page will become unavailable.

    The vSphere Data Protection Administration Guide references the emwebapp.sh script three times:

    • On page 32 in 'Best Practices,' there is a reference to emwebapp.sh --start.

    • On page 36 in 'Freeing up space for the upgrade,' there are two references. Step 3 includes emwebapp.sh --stop, and step 9 includes emwebapp.sh --start.

  • VMDK Backup Job silently fails when single vmdk is migrated to a different datastore (222957)

    During a migration of an individual VMDK from one datastore to another, VDP attempts to update all backup jobs that contain the disk that was migrated. In some instances, VDP cannot accurately determine where the disk referenced by the backup job was migrated to. In this case, the backup job is not updated. One instance of this issue is when the disk folder name on the new datastore is different than the folder on its original datastore. If VDP cannot determine where the VMDK is migrated to, VDP sends a vCenter alert that the backup job may no longer be accurate.

    If the VDP Appliance is shut down or the emwebapp.sh service is stopped at the time of the VMDK migration, VDP cannot detect the migration. The backup jobs are not updated. If backup jobs are out of sync, no alert is sent to vCenter. If a backup job is out of sync with the location of the VMDK, the backup job continues to complete successfully, but no longer backs up the disk that was migrated.

    To resolve this issue, update the backup job. Then re-add the migrated VMDK to the backup job by using the VDP vCenter plug-in.

  • Disk backups can be deleted, whereas the Admin Guide mistakenly says that you cannot delete disk backups (223217)

    The vSphere Data Protection Administration Guide requires corrections to the following topics:

    • Deleting a Backup Job topic on page 118: The following statements are invalid and will be deleted in the next version of this guide: 'You cannot delete backups that were run on individual disks. You can only delete full image backups.'

    • Deleting a Backup from the Restore Tab on page 132: The statement 'You can only delete full image backups' should be restated as, 'They can only be deleted along with the deletion of full image backups.'

  • Add documentation to the admin guide to indicate that VDP 6.0 will not support VVOL (223246)

    VDP 6.0 does not support backups and restores of VMs on Virtual Volumes (VVOLs).

  • User must disable vMotion during backup window and before running restores to new (224181)

    During the backup window and before running a restore to a new location, you must disable the vMotion feature at the VM and datastore levels.

    1. From a web browser, access the vSphere Web Client:

      https://<IP_address_vCenter_Server>:9443/vsphere-client/

    2. Select vCenter > Hosts and Clusters.
    3. Select the DRS tab.
    4. Select the Manual checkbox for all DRS clusters listed in the left menu.
    5. Select Inventory > Datastores.
    6. For each datastore where VMs, proxies, and VDPs reside, do the following:
      1. Select the datastore.
      2. Select Edit Settings.
      3. On the left menu under General, click SDRS Automation.
      4. In the right panel, select No automation (Manual).
      5. Select Virtual Machine Settings.
      6. Ensure that all VMs show Disabled or Manual for the SDRS Automation.
  • Cannot replicate Imported image backups (224280)

    For imported backups, the import process moves the clients and accounts from their current account path to /REPLICATE/VDP_IMPORTS/. The name of the domain at this level includes a timestamp, which is appended to the end of the name. The import process also deletes all jobs. Chill global for mac free. To replicate these backups, you must select replicated backups for the type, and then select imported backups.

  • Customer Experience Improvement Program (PhoneHome) is not supported in a pure IPv6 vSphere Data Protection environment (225343)

Interoperability Issues

  • In a VSAN environment, the image-level restore to original location operation is allowed, but the disk-level restore to original location operation is grayed out, after migrating the entire virtual machine to another datastore (58839)

    Workaround:

    Either restore the entire VM with an image-level backup or restore the disk level backup as a new disk on the original VM.

VMDK Issues

  • Incorrect behavior of the VDP Appliance when more disks are added to the same SCSI slots (59774)

    The VDP Appliance initiates a restore operation with the same SCSI IDs on the same existing VM assigned to two different restore points. In addition, the Summary page incorrectly indicates that two new virtual disks will be added. The Restore operation completes successfully without informing the user that only the first single disk was added, and the second disk simply replaced the first disk.

General VDP Appliance Issues

  • A password change on a configured vCenter Server is not allowed on the VDP Appliance, even after the vCenter Server password has expired (59497)

    The VDP-Configure application does not allow a password change for the configured vCenter if backups are in a Running state on the server. If the user password on the configured vCenter has already expired, no tasks are posted on the task console, and, consequently, the tasks cannot be canceled.

    Workaround:

    Perform the following steps:

    1. Wait until all the backups and tasks finish in the VDP Appliance and then change the password.

    2. Restart the VDP Appliance in the maintenance window, and then log into the VDP-Configure user interface and change the vCenter password from the VDP-Configure user interface.

  • The Performance Assessment Test (PAT) result changes to Never Run when the datastore name is changed (59784)

    In this scenario, the user opens the VDP-Configure user interface, clicks the Storage tab, selects a datastore, and clicks the Run performance analysis on storage configuration checkbox. The performance analysis test completes successfully and the results of the performance analysis are displayed correctly. If the user changes the name of the datastore, however, the performance analysis results erroneously indicate the status as Never Run.

  • VDP server is prone to man-in-the-middle attack (197873)

    After you enable the SSL configuration to secure a connection between vCenter and VDP, a user is unable to connect from the VDP plug-in. As a result, the following error appears in the vdr-server.log:

    javax.net.ssl.SSLHandshakeException:java.security.cert.CertificateException: No subject alternative names matching IP address x.x.x.x found

    Root Cause:

    The vCenter server is registered to VDP by using a vCenter IP address. No subject alternate name is available in the vCenter certificate.

    Workaround:

    Use one of the following workarounds:

    • Regenerate the self-signed vCenter certificate and add the subject alternate name to include the IP address.

    • Reregister the vCenter with VDP by using the fully qualified hostname that was provided in the vCenter certificate. If you choose to reregister by using a fully qualified hostname, all backup jobs and policies will be deleted. You must re-create the backup jobs and policies after you make changes to the configuration. Restore jobs and backups are not affected.

  • Though the Automatic Backup Verification (ABV) jobs succeed, VDP always shows the ABV jobs as 'never' under the 'Completion' column on the Reports tab or the Backup Verification tab (233385)

Workaround:

Restart the emwebapp.sh service by running the emwebapp.sh -restart command.

Backup Issues

  • Loading clients takes a significant amount of time when editing or cloning a backup job (60249)

    The edit or clone action of a backup job for a SharePoint server (upgraded plug-in) takes 5 to 10 minutes to load clients. In addition, some delay occurs when loading clients for Microsoft Exchange and SQL servers that were created before an upgrade.

    This is a known issue that will be fixed in a future release.

  • Backup of a VM fails when ESX is moved from one datacenter to other within same vCenter inventory (207375)

    After you move an ESX host from one datacenter (Datacenter A) to another (Datacenter B), and then perform a manual backup of a VM client in the Datacenter B, the backup might fail. The error log shows that the backup job still refers to Datacenter A instead of Datacenter B.

    To work around this issue, perform one of the following steps before you run a manual backup of the VM:

    • Wait for 24 hours. This enables the backup job to reflect the correct datacenter.

    • Run the following mccli vmcache sync command:

mccli vmcache sync --name=vCenter_ipaddress --domain=/vCenter_ipaddress

Restore Issues

  • If a virtual machine is deleted during a VDP restore operation, the virtual machine is not properly removed from the VDP inventory. This causes an error when editing the backup jobs that included the deleted virtual machine as source. Additionally, if a virtual machine is created with the same name, attempts to add the virtual machine to a backup job will fail. (35110)

    Workaround:

    As a best practice, avoid deleting virtual machines during restore operations. If this error does occur, create the virtual machine with a new name and add it to a new backup job.

  • File Level Restore (FLR): 'Error 10007: Miscellaneous error' is displayed for most of the FLR failures (45699)

    The 'Error 10007: Miscellaneous error' message is displayed for most of the FLR failures. In addition, FLR does not display any error message in cases where there is a restore failure due to the disk being full or a long file path. Therefore, it is impossible to determine the root cause of the FLR failure.

  • Deleted disks are skipped when restoring to original location (53004)

    If the target VM no longer has the same disk footprint as the original VM that was backed up (if the disks have been removed or deleted from the VM), performing a 'Restore to original location' operation, after selecting a restore point timestamp in the Restore pane, will silently fail to restore the missing disk of the VM.

    Workaround:

    Restore the disk to its original location after manually adding the missing disk to the VM. Ensure the disk is the same size as it was when the VM was backed up. If this workaround fails, restore the disk to a new location to create a new VM. When the restore task completes, detach the restored disks from the new VM and attach them to the required VM using the information in 'Detaching and Reattaching Storage' of the vSphere Data Protection Administration Guide.

  • File Level Restore (FLR): Need proper error message for failure to load EXT4 partition tree with internal proxy (191574)

    FLR browsing of an EXT4 partition with an internal proxy is not supported. If the user performs this action, no proper error is prompted.

  • Restore backup of secondary replica failed or aborted with log gap error (197652 CLONE: 197437)

    When restoring an incremental backup of a secondary replica, the restore returned a failed / aborted status and the log indicates the log gap error, though the database has no log gap. Note that this issue has not been observed in restoring a backup of a primary replica.

    The issue is AlwaysOn nodes synchronization-related and occurs during the creation of SQL metadata file in the backup workflow, in cases where the backup is taken on a secondary AlwaysOn replica.

    This issue results in backups with a corrupted metadata file, so users could not perform a Log tail recovery or some additional differential / incremental backup could not be linked to this backup chain.

    There is no data loss.

    Workaround:

    Perform a full backup. Ensure the 'Force incremental backup after full backup' backup option is unchecked.

Replication Issues

  • Replication of replicated clients under a particular tenant on the target server fails (194669)

    The replication of replicated clients from a source to a target server under a particular tenant account fails with the following error message:

    Specified account ( ) does not fall within the current authorization domain.

    In addition, the failure occurs with the following source/target combinations:

    • Source server: VDP Advanced and Target Server: VDP Advanced / Replication Target Identity (RTI)

    • Source server: RTI and Target Server: RTI / VDP Advanced

  • Replication Recovery: Replication logs are filling up the root partition - need to create a symlink to another partition (195196)

    The replication logs are currently going to the /space partition and not to the root partition.

    Workaround:

    Manage the replication logs in the /usr/local/Avamar/var/client directory (the space partition).

  • Replication succeeds when there are no restore points (196573)

    Replication jobs run and complete successfully, even after the restore points have been deleted. The replication job, however, does not replicate the backups. The expected behavior is the job should fail as there are no restore points to replicate.

    This is a known issue that will be fixed in a future release.

Microsoft Application (MS App) Issues

  • On Microsoft Exchange clients, there are many warning messages in the avagent log that print frequently and fill up the logs (56723)

    The Microsoft Exchange client is left registered with two VDP Advanced Appliances in the vCenter, which is causing this issue.

  • Upgrade 2014: The Backup Agent user is reset to Local System after upgrading the Microsoft Exchange client plug-in (191795)

    When upgrading the Microsoft Exchange client plug-in from the previous version of the VDP Advanced Appliance to the current VDP Advanced Appliance, the backup agent service logon user is reset to Local System, rather than Backup User.

    From VDP version 5.5.6 to 5.8, the system resets the credentials to local system credentials without asking for permission, causing the backup job to fail

    Workaround:

    To edit the Microsoft Exchange backup job or to create a new Microsoft Exchange backup job, the user must manually configure the backup agent service. To do this, the user must enter the username and password using the Backup User Configuration Utility.

Automatic Backup Verification (ABV) Issues

  • ABV: Verification job fails after renaming the datastore (55790)

    This error can occur if you rename or move the destination datastore outside of VDP.

    Workaround:

    Edit the verification job and select the renamed or moved destination datastore as the new destination. For instructions, refer to 'Editing a Backup Verification Job' in the vSphere Data Protection Administration Guide.

  • ABV: Verification job fails to initiate when destination path for host is changed (55795)

    Workaround:

    Edit the verification job and select the appropriate destination path when you perform the verification job.

  • Improper error messages are reported if the Verification job failed because of connection issues due to Data Domain (56619)

    The backup cannot be restored and the Verification job fails because the VDP Appliance cannot talk to the Data Domain. It is expected for the Verification job to fail; however, the proper error message does not display and the user does not know the root of the failure.

Resolved Issues in VDP 6.0.1

The following table lists the issues that have been resolved in VDP 6.0.1:

Defect NumberDescription
222603The delete and edit operations on a VDP appliance that has more than 15 backup jobs take more than 10 minutes each to complete.
225694CPU consumption does not decrease after an email schedule has been triggered for longevity scale setup.
225816VDP takes a long time to open jobs such as, backup, automatic backup verification, and replication for editing.
229809The browsers that end trust for SHA-1 SSL certificates for VDP require update.
232716The backup job status incorrectly appears in VDP on the vSphere web client and the email summary report.
PR 1404886VDP crashes while creating or performing backup jobs.
vSphere Data Protection (VDP) 6.1 Release Notes 10 SEP 2015

These release notes include the following topics:

Vsphere

Benefits and Features

Read about the benefits and features of this product at the following links:

Supported Environments

For information on supported environments, see the VMware Interoperability Matrix.

Known Problems and Limitations

The following are the known problems and limitations in this release of VDP.

VMware Issues

  • Support for routed / NAT / Firewall / IDS / TSNR between the VDP Appliance and the vCenter (1292848)

    When configuring the network for the VDP Appliance and the vCenter, modifying network address information using NAT or other configuration methods (for example: firewall, IDS, or TSNR) is not supported. When those tools are deployed as part of the virtual network, some VDP functionality may not work as designed.

Documentation Issues

  • The SQL Server 2005 section in the 'VDP Application Support' chapter of the vSphere Data Protection Guide (versions 5.8 and 6.0) erroneously claims 'x64' support

    The text currently reads as follows:

    SQL Server 2005 SP3 x64 on:

    • Windows Server 2003 SP1 or later, x86/x64
    • Windows Server 2003 R2, SP2 or later, x86/x64
    • Windows Server 2008 SP1 or later, x86/x64
    • Windows Server 2008 R2, x64

    Note the SQL Server should read: 'SQL Server 2005 SP3' (remove 'x64'). The bullet points are correct.

  • Powering On of VM fails when backed up VM was connected to DVS and restored to other ESX (222475)

    When powering on a VM after you restore it, vCenter returns a PowerOnFailure error similar to the following:

    DRS cannot find a host to power on or migrate the virtual machine. Network interface 'Network adapter 1' uses network '77 d3 02 50 5f 76 ca d7-db f9 42 6c 0f 6f 87 1f', which is not accessible

    This error message occurs when the environment where you restore the VM does not have the network connection that was present when you backed up the VM. For instance, a user backs up a VM that is connected to a distributed vSwitch. Then the user restores the VM to an ESX host that is part of a Distributed Resource Scheduler (DRS) cluster. The vSwitch does not exist in the DRS cluster. Powering on the VM, therefore, fails.

    Workaround:

    Edit the VM settings, set the network connection to the network adaptor, and then power on the VM.

  • Add documentation to the admin guide to indicate that VDP 6.0 will not support VVOL (223246)

    VDP 6.0 does not support backups and restores of VMs on Virtual Volumes (VVOLs).

  • Customer Experience Improvement Program (PhoneHome) is not supported in a pure IPv6 vSphere Data Protection environment (225343)

Interoperability Issues

  • In a VSAN environment, the image-level restore to original location operation is allowed, but the disk-level restore to original location operation is grayed out, after migrating the entire virtual machine to another datastore (58839)

    Workaround:

    Either restore the entire VM with an image-level backup or restore the disk level backup as a new disk on the original VM.

VMDK Issues

  • Incorrect behavior of the VDP Appliance when more disks are added to the same SCSI slots (59774)

    The VDP Appliance initiates a restore operation with the same SCSI IDs on the same existing VM assigned to two different restore points. In addition, the Summary page incorrectly indicates that two new virtual disks will be added. The Restore operation completes successfully without informing the user that only the first single disk was added, and the second disk simply replaced the first disk.

VDP Issues

  • A password change on a configured vCenter Server is not allowed on the VDP Appliance, even after the vCenter Server password has expired (59497)

    The VDP-Configure application does not allow a password change for the configured vCenter if backups are in a Running state on the server. If the user password on the configured vCenter has already expired, no tasks are posted on the task console, and, consequently, the tasks cannot be canceled.

    Workaround:

    Perform the following steps:

    1. Wait until all the backups and tasks finish in the VDP Appliance and then change the password.
    2. Restart the VDP Appliance in the maintenance window, and then log into the VDP-Configure user interface and change the vCenter password from the VDP-Configure user interface.
  • The Performance Assessment Test (PAT) result changes to Never Run when the datastore name is changed (59784)

    In this scenario, the user opens the VDP-Configure user interface, clicks the Storage tab, selects a datastore, and clicks the Run performance analysis on storage configuration checkbox. The performance analysis test completes successfully and the results of the performance analysis are displayed correctly. If the user changes the name of the datastore, however, the performance analysis results erroneously indicate the status as Never Run.

  • VDP 6.1 does not support the traditional Chinese locale (235157)
  • VDP GUI displays an error message in the Firefox browser when you edit a Data Domain device (231126)

    If you edit a Data Domain device by using the VDP GUI or the VDP configuration utility in the Firefox browser, an error message, which states that editing the Data Domain device has failed, appears even though the configuration is correct.

    Workaround:

    Use either the Chrome browser or the Internet Explorer browser.

  • The Configuration tab page displays the services are not running messages after either restarting VDP or initial configuration (235086)

    After either restarting VDP or initial configuration, the Configuration tab page of the VDP configuration utility displays the following messages, and the proxies' status in red.

    • Backup and recovery services are not running.
    • File Level Restore service is not running.

    The messages disappear after 20 minutes.

    Workaround:

    To make the messages immediately disappear, click the refresh button beside Proxies.

  • The status of the Data Domain devices on the Storage tab page appears wrong after either changing the VDP password or restarting the management service (237934)

    After either changing the VDP password or restarting the management service, the following message appears on the Storage tab page for the Data Domain devices:

    Data Domain storage status not available. Unable to retrieve ssh key file pair.

    However, after approximately 20 minutes, the Data Domain devices appear online.

  • vCenter certificate does not appear in the vCenter Registration window though the certificate is uploaded during the initial configuration of vCenter (238242)

    Though the vCenter certificate is uploaded during the initial configuration of vCenter, the certificate does not appear in the vCenter Registration window of the VDP configuration utility. Also, the user selection does not persist.

    You must upload the vCenter certificate whenever you register vCenter.

  • If a vCenter Server has VDP appliances of multiple versions, the UI of any VDP version displays the features of the latest version (235357)

Backup Issues

  • Loading clients takes a significant amount of time when editing or cloning a backup job (60249)

    The edit or clone action of a backup job for a SharePoint server (upgraded plug-in) takes 5 to 10 minutes to load clients. In addition, some delay occurs when loading clients for Microsoft Exchange and SQL servers that were created before an upgrade.

    This is a known issue that will be fixed in a future release.

Migration Issues

  • A backup verification job does not migrate the verification script parameters (238608)

    After migrating a backup verification job that contains the verification script parameters to an Avamar server, clicking More Options.. on the Avamar Administrator > Policy Management > Edit VM Backup Validation Group > Overview page does not display the verification script parameters of the migrated job.

  • After migrating to VDP 6.1, you cannot perform a restore to the original location (240401)

Restore Issues

  • If a virtual machine is deleted during a VDP restore operation, the virtual machine is not properly removed from the VDP inventory. This causes an error when editing the backup jobs that included the deleted virtual machine as source. Additionally, if a virtual machine is created with the same name, attempts to add the virtual machine to a backup job will fail. (35110)

    Workaround:

    As a best practice, avoid deleting virtual machines during restore operations. If this error does occur, create the virtual machine with a new name and add it to a new backup job.

  • File Level Restore (FLR): 'Error 10007: Miscellaneous error' is displayed for most of the FLR failures (45699)

    The 'Error 10007: Miscellaneous error' message is displayed for most of the FLR failures. In addition, FLR does not display any error message in cases where there is a restore failure due to the disk being full or a long file path. Therefore, it is impossible to determine the root cause of the FLR failure.

  • Deleted disks are skipped when restoring to original location (53004)

    If the target VM no longer has the same disk footprint as the original VM that was backed up (if the disks have been removed or deleted from the VM), performing a 'Restore to original location' operation, after selecting a restore point timestamp in the Restore pane, will silently fail to restore the missing disk of the VM.

    Workaround:

    Restore the disk to its original location after manually adding the missing disk to the VM. Ensure the disk is the same size as it was when the VM was backed up. If this workaround fails, restore the disk to a new location to create a new VM. When the restore task completes, detach the restored disks from the new VM and attach them to the required VM using the information in 'Detaching and Reattaching Storage' of the vSphere Data Protection Administration Guide.

  • Restore of a secondary replica fails or aborts with a log gap error (197437)

    When you restore an incremental backup of a secondary replica, the operation returns either a failed or an aborted status and the log indicates the log gap error though the database has no log gap. The issue does not occur when you restore a primary replica.

    The issue relates to the synchronization of the AlwaysOn nodes, and occurs during the creation of SQL metadata file in the backup workflow, in cases where you back up a secondary AlwaysOn replica.

    The issue results in backups with a corrupted metadata file. So, you cannot either perform a log tail recovery or link differential or incremental backups to this backup chain. However, there is no data loss.

    Workaround:

    Perform a full backup. Ensure that the Force incremental backup after full backup option is not selected.

  • Canceling a restore operation does not delete the restored data on a VM (237125)

    While performing a restore to a different VM that is not the source VM, if you cancel the operation, the cancelation succeeds, but the already restored data that is part of the canceled restore is not deleted from the VM.

  • Restoring to the same source location on a VM by selecting the Restore along with configuration option fails (237015)

    If the source virtual disks are removed on a VM, and you restore the same virtual disks to the same source location on the VM by selecting the Restore along with configuration option, the operation fails.

    Workaround:

    Perform the restore to an alternate location.

Replication Issues

  • Replication of replicated clients under a particular tenant on the target server fails (194669)

    The replication of replicated clients from a source to a target server under a particular tenant account fails with the following error message:

    Specified account ( ) does not fall within the current authorization domain.

    TSC TTP-244 Plus Windows printer drivers by Seagull Scientific make it easy to print labels, cards and more from any Windows program, including our BarTender software. TTP-244 Plus TDP-247 Series: Download: MAC driver MAC driver For MAC OS V10.6 V10.15. 2.96 MB: 2020/03/05: TDM-30 TDM-20 MH240 Series TTP-2410MT Series TTP-244M Pro Series TTP-246M Pro Series ME240 Series TX200 Series TTP-247 Series TE200 Series TC Series TA210 Series TTP-243 Pro Series. TTP-244 PLUS DRIVER FOR MAC DOWNLOAD - No other printer can easily power a meter thermal transfer ribbon along with a full 8 OD roll of labels. Find more suppliers in Chennai. Mac TSC 244 DRIVER FOR MAC The TTP Plus offers the largest media and ribbon capacities in its class. This is a good quality easy to use label printer. Was this review helpful? Driver link: This video shows the detailed steps to setup and install TSC TTP 244 Plus printer in your Mac.

    In addition, the failure occurs with the following source/target combinations:

    • Source server: VDP Advanced and Target Server: VDP Advanced / Replication Target Identity (RTI)
    • Source server: RTI and Target Server: RTI / VDP Advanced
  • Replication Recovery: Replication logs are filling up the root partition - need to create a symlink to another partition (195196)

    The replication logs are currently going to the /space partition and not to the root partition.

    Workaround:

    Manage the replication logs in the /usr/local/Avamar/var/client directory (the space partition).

  • Replication succeeds when there are no restore points (196573)

    Replication jobs run and complete successfully, even after the restore points have been deleted. The replication job, however, does not replicate the backups. The expected behavior is the job should fail as there are no restore points to replicate.

    This is a known issue that will be fixed in a future release.

Microsoft Application Issues

  • On Microsoft Exchange clients, there are many warning messages in the avagent log that print frequently and fill up the logs (56723)

    The Microsoft Exchange client is left registered with two VDP Advanced Appliances in the vCenter, which is causing this issue.

  • Upgrade 2014: The Backup Agent user is reset to Local System after upgrading the Microsoft Exchange client plug-in (191795)

    When upgrading the Microsoft Exchange client plug-in from the previous version of the VDP Advanced Appliance to the current VDP Advanced Appliance, the backup agent service logon user is reset to Local System, rather than Backup User.

    From VDP version 5.5.6 to 5.8, the system resets the credentials to local system credentials without asking for permission, causing the backup job to fail

    Workaround:

    To edit the Microsoft Exchange backup job or to create a new Microsoft Exchange backup job, the user must manually configure the backup agent service. To do this, the user must enter the username and password using the Backup User Configuration Utility.

  • VDP 6.1 does not support the skip log gap detection feature of SQL Server (196513)
  • You cannot back up the SharePoint Server databases if the database names contain unicode characters (192449)
  • You cannot perform a Granular Level Recovery (GLR) on an Exchange client (238439)

    You cannot perform a GLR on an Exchange client if the GLR plug-in is not installed. Even if you install the GLR plug-in by using the repair option of the Exchange client installer, you cannot perform the GLR.

    Workaround

    1. Uninstall the Exchange client.
    2. Run the Exchange client installer.
    3. On the Feature selection page, select the GLR feature.
    4. Complete the installation.

Automatic Backup Verification (ABV) Issues

  • ABV: Verification job fails after renaming the datastore (55790)

    This error can occur if you rename or move the destination datastore outside of VDP.

    Workaround:

    Edit the verification job and select the renamed or moved destination datastore as the new destination. For instructions, refer to 'Editing a Backup Verification Job' in the vSphere Data Protection Administration Guide.

  • Improper error messages are reported if the Verification job failed because of connection issues due to Data Domain (56619)

    The backup cannot be restored and the Verification job fails because the VDP Appliance cannot talk to the Data Domain. It is expected for the Verification job to fail; however, the proper error message does not display and the user does not know the root of the failure.

  • ABV does not start if the last backup completed with an exception (206091)

Fixed Problems

The following table lists the problems that have been fixed in this release of VDP:

Defect NumberDescription
222603The delete and edit operations on a VDP appliance that has more than 15 backup jobs take more than 10 minutes each to complete.
225694CPU consumption does not decrease after an email schedule has been triggered for longevity scale setup.
225816VDP takes a long time to open jobs such as, backup, automatic backup verification, and replication for editing.
229809The browsers that end trust for SHA-1 SSL certificates for VDP require update.
230593VDP crashes while creating or performing backup jobs.
233382Restoring workorder id for vCenter tasks requires prefixing the client name.
235375Opening a restore rehearsal or a backup now wizard from VC inventory throws a flex exception.
39456Initial creation of large scale (100 VM) backup job takes a long time (10+ minutes).
194717Accessing backups for multiple clients on the recover wizard is very slow.
207133Replication default job duration requires modification.
222963Selecting Distributed Virtual Port Group for network fails to deploy a proxy VM.
232550Encrypted responses are displayed in the HTML format.
37897If you concurrently select a large number, more than 100, of restore points, a few restore points are not locked, unlocked, or deleted.
197992If you simultaneously run the Exchange backup jobs for DAG cluster and DAG passive member, the backup jobs fail.
223739Exchange Server 2013 DAG federated GLR redirected recoveries to a mailbox server that is not part of the DAG fail.
230098GLR restore error :avexchglr Error <13378>: Failed to find C:Program FilesavpvaravfscacheAVFSMOUNTpchs-exch-pv02_00000000F$Program FilesMicrosoftExchange ServerV15MailboxStaffFaculty*.edb
230752You cannot restore a subset of databases if a backup contains the DAG databases that are active on another node.
60530VDP restore fails if a backup contains special characters in the database names.
55338An RDB restore of an entire backup must be allowed if the backup contains a single database.
223328Completed Tail-Log backups of SQL Server are not available for restore.
238924NGC error #1009 occurs if you restore a disk to a different location.
223855Exchange Server 2013 DAG database recoveries do not validate the suspension of the DAG database replication.
230947Exchange Server 2013 backup fails if the server hosts the suspended copy of a database.
223797Simultaneous scheduled backups of two Availability Group clients to the same secondary replica fail and display lock error.
224298You cannot edit a backed up job if the backed up VM exists in a datacenter that exists in a folder at the vCenter root level.
55795Verification job does not start if the destination path for a host is changed.
231287GLR-browsing two mail boxes on an Exchange Server results in the avmapi error 0x80005010.
234895The admin user does not have the Read permission for the log files.
232552Ciphers are not compliant with VMware's Product Security Requirements (PSR).
232335The VDP console must display the thumbprint of the VDP server certificate.
232355You do not require the current password to change the password in the VDP configuration utility.
232433SSL/TLS certificate validation is disabled by default.
232434VDP does not validate the certificate while either testing the connection or registering the vCenter server.
234979The VDP configuration utility requires an option to enable or disable the vCenter certificate verification.
197873A VDPA server is prone to the man-in-the-middle attacks.
207375A VM backup fails if the ESX server is moved from one datacenter to another within the same vCenter inventory.
232352The VDP configuration utility requires eliminating the session fixation vulnerability.
228510The VPXD logs display the 'SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number' error.
230978The VM image level backups require detecting the consistency level.
231064The vSphere web client and the Email Summary report incorrectly display the VDP backup job status.
195497Performing a restore to original does not revert the configuration changes.
224650You cannot perform a File Level Restore from the MC_RETIRED and REPLICATE domains.
231693Advanced login to perform an FLR fails if the user is a member of the AD Group.
233432The VDP UI displays the ABV job details in the never under completion column though the ABV job succeeded.
235593If you initiate an FLR, the restore job is initiated multiple times for the same FLR.
53520An FLR client displays duplicate loading signs and restore points when backups are being mounted.
224256The Outgoing mail server field does not accept an IPv6 address.
236692The VDP Exchange client installation in Japanese fails and displays the Transforming Table Error message.
231891The backup agent service for a SQL failover cluster instance is not created on the passive node.
232553Configuring the network does not require a password.
236763A VMDK backup job silently fails after migrating a disk to a different datastore.

Popular Posts