Just ahead of its Pulse event next week in Las Vegas, IBM introduced v6.2 of Tivoli Storage Manager (TSM).  The three big themes were unified recovery management, improved backup of virtual machines, and enhanced deduplication.

TSM is the granddaddy of unified recovery management platforms.  IBM has (through mostly home-grown development) integrated a number of functions to streamline recovery management from a single user interface and policy engine. IBM took steps to further integrate TSM FastBack (FilesX technology IBM acquired in 2008) with TSM via the TSM Admin Center.

I was excited to hear that TSM was improving its support for VMware vSphere and Microsoft Hyper-V (surprisingly, only a handful of backup vendors are at this point), but was later disappointed to learn that it’s superficial at this time.  VMware introduced several new features in vSphere 4—most notably re-architecting the facilitation of backup.  VMware replaced VCB (the biggest afterthought of the platform) with new APIs for data protection (VMFS drivers to access data on VMFS volumes), greatly improving the implementation of backup for the platform—for vendors and end-users.

But something happened on the way to the Forum … IBM neglected to take advantage of several rich features in vSphere 4 that create efficiency.  Specifically, IBM is not supporting changed block tracking (CBT), which would have allowed TSM to immediately identify the blocks that changed since the last backup and copy only them—cutting down the time it takes to capture and transfer data.  IBM is also not supporting a direct-to-target architecture, which would have allowed TSM to read virtual disk data directly from the SAN storage device and send it to the storage target (i.e., not drag everything around the network unnecessarily).  They also did not prioritize file-level recovery from a VM-level backup in a single step.  If you need file-level recovery, you must perform a file-level backup or a two-step recovery from a VM-level backup.  The TSM team will likely address these shortcomings in a subsequent release.

The same goes for Hyper-V.  Kudos to IBM for supporting VSS snapshots for file systems and applications in the guest operating system.  However, TSM is not supporting the off-host mode (VSS transportable snapshot).   TSM got two out of three on Hyper-V r2 features, supporting LiveMigration and Cluster Shared Volumes (CSV), but not item level recovery.

Luckily for TSM users, IBM is further along in its deduplication strategy.  The big news?  Source-side deduplication.  In TSM 6.1, IBM introduced block-level deduplication for data after it was written to the storage pool (post-process, target-side approach) as an integrated no-fee feature for Extended Edition customers.  In TSM 6.2, dedupe is going upstream to introduce efficiency.  Duplicates are now identified at the source system (inline, source- or client-side approach) via a hash calculation (reducing network traffic) and leveraging a local hash index for better performance (less “chatter” between source system and media server).  The caveat?  This is only available for file data—no support for application data … yet.

IBM’s strategy to trickle its TSM feature enhancements in these dot releases allows them to respond to clients’ immediate needs and evolve their platform.  But it’s also a bit of a tease, and unless you have a glimpse into the roadmap to know what’s next, the strategy could leave some unsated.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Tags: backup, deduplication, FastBack, Hyper-V, IBM, Microsoft, recovery, source-side deduplication, target-side deduplication, TSM, VMware, vSphere, VSS