We discovered that using TSM 6.2.2 to perform vStorage API image backups also 
enables vSphere Change Block Tracking (CBT) on each vmWare guest image that it 
backs up. It would be good to document this in the TSM documentation. Upon 
additional testing it appears that even though TSM enables CBT, TSM 6.2.2 has 
no provisions to take advantage of the information provided by vSphere through 
CBT to allow incremental backups of images (only backup changed blocks). This 
is a pretty substantial defect in the product and causes backup times to be 
unnecessarily long since every image backup request requires a full image to be 
backed up. The hope would be that in the future TSM would be capable of 
performing a full image backup initially and then perform incremental backups 
as requested until another full backup is requested.

A side-effect of TSM 6.2.2 enabling CBT is that if you then storage-motion a 
virtual machine that has already been backed up to TSM, TSM has issues backing 
up the image until you reset CBT tracking on the guest. Fortunately TSM 
provides a -testflag parameter that can be passed while backing up a guest to 
reset CBT, however it would be better if TSM could detect this condition and 
reset CBT tracking without failing the backup of the virtual machine and 
requiring intervention by the administrator.

Based on what we have seen it appears that full image backups using the 
vStorage API in TSM is a work-in-progress. Your success, or lack of, in 
establishing a reliable virtual machine backup using TSM 6.2.2 would be due to 
the fact that vStoreage API support is relatively new and is still a "work in 
progress"...

There is also a minor issue with the GUI client where it miss-groups virtual 
machines that are similar in name as through they had been stuffed into the 
same virtual machine backup. For instance if you have had virtual machines 
named test, test1, test2, and test3 and you backed up all of these virtual 
machines to one TSM node ID when you go into the GUI client and attempt to 
restore the virtual machine test you would also see that test1, test2, and 
test3 were all listed as active backups under test as though they belonged to 
the same backup filesystem. This is just a visual issue with the GUI and not a 
problem with all of these backups being a part of the same filesystem. If you 
use the command-line TSM client you can verify that the backups are being 
stored correctly in TSM. They are simply not being displayed correctly in the 
GUI.


WPinegar wrote:
> Here is another issue that we encountered while testing the TSM 6.2.2 client 
> configured to use vmWare vStorage API's for virtual machine backups. If you 
> attempt to have the TSM vSphere backup proxy back itself up using the "backup 
> vm 'proxyname'" TSM command (when the proxy is also a vmWare guest) the 
> backup will succeed but at the end of the backup TSM will issue a series of 
> commands that will remove both the hot-added disk from the proxy (which it 
> should do) as well as the local hard disk from the proxy (which it should 
> never do). This, of course, causes the proxy to crash and become unbootable 
> because there is no local disk defined in the configuration of the host. 
> Fortunately recovery is fairly simple because the disk hasn't been deleted -- 
> it has just been removed from the guest config and can simply be added back 
> to the guest. But you'll need to manually cleanup the snapshots that TSM left 
> on the host.
>


+----------------------------------------------------------------------
|This was sent by wpinegar AT stdom DOT com via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------