Backup versions of VMware guests created by the IBM Spectrum Protect 22.214.171.124 backup-archive clients can be inadvertently bound (or rebound) to the wrong management class when INCLUDE.VM is used to bind the backups to a specific management class and the casing of the VM name in the INCLUDE.VM setting does not match the casing of the name in VMware vSphere. This can lead to premature loss of older backup versions if the default management class specifies a fewer number of versions or shorter retention for extra versions.
Note: Beginning with Version 7.1.3, IBM Tivoli® Storage Manager for Virtual Environments is now IBM Spectrum Protect for Virtual Environments. Some applications such as the software fulfillment systems and IBM License Metric Tool use the new product name. However, the software and its product documentation continue to use the Tivoli Storage Manager for Virtual Environments product name. To learn more about the rebranding transition, see technote 1963634.
Backups for a given VM are normally bound to a management class according to the rules listed below. The rules are in decreasing order of precedence. That is, rule 3 applies only if rules 1 and 2 do not apply; and rule 2 applies only if rule 1 does not apply.
- If the VM name matches the name specified in an include.vm option and the include.vm option also include a management class name, then the backups for the VM are bound to that management class.
- If the vmmc option specifies a management class, then backups for the VM are bound to that management class.
- Backups for the VM are bound to the default management class of the IBM Spectrum Protect server policy domain.
In versions of the backup-archive client prior to 126.96.36.199, the VM guest name specification in the include.vm option was not case sensitive. However in IBM Spectrum Protect 188.8.131.52, the guest name specification became case sensitive. Therefore this can cause VMware guest virtual machine (VM) backups to be bound (or rebound) to the wrong management class when all of the conditions listed below are true:
- The include.vm option is used to bind VMware guests to a given management class
- The guest name specification in the include.vm option is fully qualified or partially qualified
- The casing of the guest name specification in the include.vm does not match the casing of the guest name as it appears in VMware vSphere
For example, if a VMware guest name "Corp HR 1" should be bound to management class "RET1YR", then an include.vm option could be coded like this:
- include.vm "corp hr 1" ret1yr
Backup-archive client versions below 184.108.40.206 will bind backups of "Corp HR 1" to the RET1YR management class. After installing the 220.127.116.11 client, new backups of "Corp HR 1" are instead bound to the management class specified by the vmmc option or, if vmmc is not used, the default management class, as described in rules 2 and 3 above. Prior backup versions of "Corp HR 1" will likewise be rebound to management class specified by vmmc or the default management class.
The problem occurs because the code change introduced in 18.104.22.168 requires VM guest names in include.vm option settings to match the actual VM guest name casing. That is, the problem does not occur if the include.vm option setting is specified like this:
- include.vm "Corp HR 1" ret1yr
Note that the management class name remains case insensitive.
The following are possible consequences of this problem:
- The wrong number of backup versions are kept if the management class specified by vmmc or the default management class maintains a different number of backup versions than the management class specified by include.vm. This can result in fewer or greater backup versions than intended. For example, if the management class specified by the vmmc option (or the default management class if vmmc is not specified) maintains 2 backup copies and the intended management class maintains 10 backup copies, only 2 backup copies will be kept. As a result, there is the potential for premature expiration of backup versions.
- Extra (all but the latest) backup versions will be kept for the wrong number of days if the management class specified by vmmc or the default management class keeps extra backup versions for a different period of time than the management class specified by include.vm. This can result in extra versions being expired sooner or later than expected. For example, if the management class specified by the vmmc option (or the default management class if vmmc is not specified) maintains extra copies for 5 days and the intended management class maintains extra copies for 30 days, extra copies will be retained for only 5 days. As a result, there is the potential for premature expiration of backup versions.
- If the management class specified by the vmmc option (or the default management class if vmmc is not specified) retains more backup versions or has a longer retention for extra versions, this can lead to an unintended increase in Tivoli Storage Manager server storage resources used to maintain the extra backup versions.
Until fixing code is available or installed, change the casing of VMware guest names in include.vm options settings to match the casing of the guest name as it appears in VMware vSphere.
- IBM Spectrum Protect 7.1.6 backup-archive client on Linux or Windows when the client is used as a data mover for Data Protection for VMware backups.
- The fix for this problem is currently targeted for version 22.214.171.124 in late July 2016, subject to change at the discretion of IBM. Until interim fix version 126.96.36.199 is available, contact IBM support for an e-fix.
Flash Change History
20 July 2016: Original text published
Was this topic helpful?
25 September 2022