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.
+----------------------------------------------------------------------
|