Rentention policy for VMware full VM backup NOT using TSM for VE

[cividan]

Hi, I need some clarification as to why my TSM Full VM backup of deleted VM are not expiring.

TSM server: 6.3.4
OS: Windows 2008r2 x64
BA client: 6.4.1
Vmware VM: ESXi 5.5

We're using BA Client Full VM backup done weekly (we do not have the license for TSMVE)

Here is my retention settings:

Policy Domain Name: STANDARD
Policy Set Name: ACTIVE
Mgmt Class Name: STANDARD
Copy Group Name: STANDARD
Copy Group Type: Backup
Versions Data Exists: 2
Versions Data Deleted: 1
Retain Extra Versions: 30
Retain Only Version: 30
Copy Mode: Modified
Copy Serialization: Shared Static
Copy Frequency: 0
Copy Destination: TAPEPOOL
Table of Contents (TOC) Destination:
Last Update by (administrator): ************
Last Update Date/Time: 06/12/2014 08:50:32
Managing profile:
Changes Pending: No

My understanding is that it should retain 1 version of the deleted VM (Version data delete=1) for 30 days (Retain Only Version=30) but when I look in my BA client GUI, I can still do a restore of a deleted VM that was last backed up on 06/28/2014. I run Full vm backup weekly. I see from the restore window that the Mgmt Class of that VM is: Standard. Which is the same of all my other VM. The retention is working good for active VM, I can restore 2 version of the VM that are still present.

If anyone can help shed some light on this for me it would be really appreciated.

 

[marclant]

VM backups do not function like file backups. Once a VM is deleted, the client just stops backing it up, it does not update the TSM Server to mark it inactive. So your last backup (or group in case of full+incrementao) is still active on the TSM Server, therefore you will be able to restore it.

Starting with 7.1, they added a mechanism to either delete VM backups, or expire (mark inactive VM backups):

[h=1]Backup-archive client updates[/h]Tivoli® Storage Manager backup-archive client version 7.1 contains many new features and changes.

VM functionality added to the delete backup and expire commands.

The delete backup and the expire command have been enhanced to support the -objtype=VM option. When this option is entered, the commands deal only with VM backups. This new feature applies to platforms that support VM.
​

• The delete backup command can be used to delete backups of VM filespaces, either active or inactive versions. When the -objtype=VM option is used, this specifies that you want to delete one or more versions of VM backups. When -objtype=VM is entered, thedeltype and filelist options can not be used.
  ​
• The expire command can be used to expire an active VM backup.​

source: http://www-01.ibm.com/support/knowl...om.ibm.itsm.client.doc/r_new_for_version.html

 

[cividan]

Thanks, I find it weird that 3 out of 4 settings in the retention policy are working fine and the last one isn't working as TSM obviously see that the VM has been deleted as the other version of the backup are deleted and when the VM is still present TSM do keep only 2 version.

 

[marclant]

It has nothing to do with the retention policy. The retention policy works fine. It's because the last VM backup is active, regardless if the VM still exists or not.

With a VM backup, the client does not check with the TSM Server to see which VMs were previously backed up, therefore does not update the server if a VM is deleted. As such, the most recent backup remains active, and active objects are never eligible for expiration. Also, when you do a new VM backup of a given VM, the previous one become inactive, so that's why they are eligible to expire when either the number of versions is reached or age.

On the other hand, with a file backup, if you backup a file one day, delete it, run another incremental, the client will see that the file exists on the server, but no longer on the client. So the client will send an expire message to the server for that file, and the server will change the status of the file to inactive. Once inactive, it's will expire from the server once the retention is met.

Someone opened an RFE earlier to request that the ability to automatically expire deleted VMs be added. You can see it here, and add your vote to it to raise visibility: https://ibm.biz/BdFYVD

 

[cividan]

Ah this reply is way more clear and now I understand. I did add my vote on the RFE but with only 10 votes I dont have big hopes

 

[cividan]

One more question, if I install the 7.1 BA client and run a script to expire all backup just before the next backup run, this would fix the lack of the BA Client to mark the backup as inactive for deleted VM but will that cause problem with TSM when the VM is still present and it will try to mark the previous one as inactive but it's already inactive ? As you can guess I'm still in the bottom part of the TSM learning curve

 

[marclant]

You might be able to do that, but it could potentially be dangerous. You only keep 2 versions, so lets say you expire the last backup of a VM, so you don't have any active versions. If the backup fails for several days in a row, longer than your retention, there is the potential to not have any backup to restore if you don't catch it in time.

The other thing, you may for some reason keep the last active backup of a particular VM, in case you want to recover it at a later day for whatever reason.

It will not try to inactivate the most current inactive though, it will just insert it as active.

The other catch is that expire command needs the actual VM name, no wildcards. So you would need to manually edit the script anytime you add a new VM. Personally, I think it would be better to manually expire the last backup when you delete a VM. So handle the deletes rather than the additions, but that's just me.

 

[cividan]

Thanks, I did tought I could use wildcard to expire everything so I agree it become more trouble than what it's worth. I will just add to my daily report the filespace with the last backup date and monitor it from there for VM that have been deleted by other VMware admin.
Thanks for your advice.

 

[marclant]

If you are good with reporting, you could even make a custom monthly report, based on your daily report, that gives you VMs that have not had a backup in X days, then deal with just those.

 

[cividan]

If you are good with reporting, you could even make a custom monthly report, based on your daily report, that gives you VMs that have not had a backup in X days, then deal with just those.

Thanks for the Idea, I had to play with my query alot to be able to achieve this as some filespace are reported with an empty "backup_END" and also I wanted only the VM filespace so it was a good challenge for my beginner reporting skill

Here is the query I ended up with to return the VM filespace that did not had a backup in more than 30 days or that the backup date is not returned in case it help somone else in the future

select filespace_name,backup_end,node_name,filespace_id,filespace_type from filespaces WHERE filespaces.filespace_type='API:TSMVM' AND ( filespaces.backup_end < (SELECT current date - 30 days FROM sysibm.sysdummy1) OR ( filespaces.backup_end  IS NULL )) ORDER BY node_name,backup_end

 

[tpesselier]

Hello

It makes another problem when you use colocation by filespace, even if you delete a vm in vmware, tsm will keep a volume.
If you do not clean you will have many empty volume

Best