Commvault vs. TSM

dangel42

ADSM.ORG Member
Joined
May 18, 2007
Messages
69
Reaction score
0
Points
0
Location
Wisconsin
PREDATAR Control23

We are in the midst of comparing TSM with Commvault. I am personally in favor of TSM but need some significant ammo to unseat the Commvault bias.

Does anyone have any real-world experience with both and can compare/contrast the two or has gone through a recent evaluation? With a TSM slant, of course. :)

Versions being compared: TSM 5.4 and Commvault 7.0(with Single Instance Store being a big part of their product)

Rough picture of our layout: 300 servers, roughly 50/50 Windows/Linux...current library is an IBM 3494 with 5 - 3590E tape drives

Thanks in advance
 
PREDATAR Control23

Boy
Where have we seen this before everyone.

Dangel42 - A colleague recently lost his position and backup environment to CommVault - simply due to money.

WE can share with you our advice and recommendations - but you what - We need some input from your Management team. If they will take to heart the "mutual concensus" of this forum - then I and possibly others will gladly share our opinions.
If you are venturing on your own - and do not have bargaining powers to convince those who pay the bills. Then start looking, update your resume, cause the end is near my friend.
Yes - We should put up a fight for you - but we need to know if this Commvault bias is bipartisan.

Good luck - Let us know
 
PREDATAR Control23

Well, I can say that money is not an issue(TSM is very aggressive) and my job isn't at risk regardless of who we pick. I'm actually new to the backup game as we transition some job responsibilities around the dept.

Anyway, what's funny is that our new management came from a TSM shop where "it just worked" and they couldn't justify replacing it because every time they performed a DR drill it worked...but at the same time he's stated to others that Commvault is the better technology.

So the bias is heavy, but it wouldn't be the first time he's changed his mind after being biased towards a vendor(aka storage).

Another nice idea being played about is to give whoever we choose 30-60 days to make their product work as designed...if not, they don't get paid and go to the other product. So, essentially I'm willing to put up a decent fight for TSM but at the same time not stepping on anyone's toes because they like Commvault and because I have some built-in insurance.
 
PREDATAR Control23

Well alrighty then - then be prepared over the next few days - to receive a whole slue of comments. Its good to know there is TSM foundation. I'll give you my input in the AM - I am out of battery power
 
PREDATAR Control23

I will be interested to seeing this thread develop, along with the comments.

My location is currently TSM and our new management also wants to replace it, but in this case it is due to the fact that they do not like the licensing costs, and that TSM was touted as being too complicated by my predecessor.

Since he has left and I have had full control, we have seen numerous successes and changes to the environment that has reduced the daily operational responsibilities. We are facing a major DR test, and everything is complete and ready to go.

I am in the middle of trying to educate upper management of just how TSM works and how not having to replace with some home grown open source modification would be a good thing.

The whole idea that you will have costs no matter which platform you choose is my challenge to explain to them. Sure TSM is expensive, but it does work.
 
PREDATAR Control23

Don't fall into the CommVault trap of "a dog and pony show". Sure it may sound cheap from the start especially from a client licensing point but to bring up several media servers? Come on - administration will kill you.

Take it from me, I fought a huge battle with them trying to keep my TSM afloat - see my previous posting about this - but management was enticed by the seemingly cheap startup cost.

What you can do is show them the benefit of "incremental" forever versus the traditional FULL-INCREMENTAL-INCREMENTAL-FULL-INCREMENTAL-INCREMENTAL backup scenario.

Ask for help from your IBM rep.
 
Last edited:
PREDATAR Control23

One of my biggest concerns is maintaining the multiple databases for the DR site

- CommServe DB
- Single Instance Store DB(Not to mention that this is version 1.0)
- Index Cache DB
 
PREDATAR Control23

OK - Well - TSM in respect to DR - as we know comes with all sorts of different flavors options etc.... Luckily there is only one perhaps two TSM DB instances to maintain. The server to server communications allow for the transmittal of the TSM DB and its copy pool to remote locations simultaneously as TSM versioning becomes more revised.
Through in the Site to Site replication tools offered by the Array vendors - with a TSM Stby receiving and applying at the other end - and you have the purrrfect solution.
The hard part is Application and DB Servers - their log retentions, roll forward options, etc... outside of TSMs responsibility.

Failsafe option - Offsite copy pool media - in one or more copies - to support the more distant locations if necessary for DR purposes.

Lets not forget Collocation by Group options as well.
Plenty of things to argue against CommVault.
 
PREDATAR Control23

The sad part of it is that Commvault seems to have answered most of the features that TSM has except for:

Clients for AS400
Clients for Z-series systems
Capability to be installed on most platforms and not just Windows
The use of non-third party database - Commvault uses MS-SQL the license of which comes with the CommServe install (at least this is what they gave us)

Collocation by group seems to have been addressed by version 7 but I still have to see this.

Most would seem to favor Commvault (sorry guys!) because of client, per core licensing which TSM does. Commvault licenses per physical CPU, so they say.

It would be hard to quantify just how many tapes would be needed to use Commvault's backup scheme (similar to NetBackup's scheme) VS TSM's "incremental forever" method. Even if the numbers turns out in TSM's favor, management may still see the way of Commvault especially with the beautiful "dog and pony show", i.e., a GUI based environment with all the bells and whistles, and working on a simple man's (definitely not for GEEKS!!) Windows environment.

I would suggest to run them side-by-side, do backups and restores, and for the ultimate test, a D/R routine. I feel, with a proper TSM setup, TSM would come on top.
 
Last edited:
PREDATAR Control23

There are significant disadvantages with respect to TSM incremental forever technology when compared directly to the CommVault technology in this space (Synthetic Full).

A benefit touted by Tivoli is that only one copy of a file is ever backed up. Subsequently, files are backed up only if they are new or changed since the last backup. TSM tracks this in its database using pointers of each version of its files for each client. This negates the need for another full backup. Restores can be the latest file or files, specific version or a point in time. These capabilities are mimiced and are available within CommVault's synthetic Full technology as well.

The TSM incarnation has a significant disadvantage as the management of files and placement on offline tape media is either unmanaged i.e. media contains files of different retention or the media is managed with reclamation and co-location processes. Both methods have issues. The former technology will result in lengthy restore process as multiple tape mounts would be required to recover files, version or specific points in time and the inability to recover media to free scratch efficiently. These limitations are in part addressed by the deployment of co-location and reclamation as these technologies will actively move content for a specific client or clients to specific pieces of media thereby ensuring data for a specific client or clients is placed on fewer tapes. This improves the recovery times of files for specific client systems.

There are two significant downsides with this process. Static files within the file system never expire. If you stop protecting the client the last image will remain unless manually deleted. This means that it is difficult to ensure that business data retention requirements are maintained across the board without complex discovery and tape management procedures put in place. Another down side relates to the size and number of drives within tape libraries. Co-location and reclamation will require that media is read post backup window and then consolidated and written to active media for the client or clients in question. Please remember that it is typical for multiple streams to be used to protect fast clients; this will require multiple tapes to be read concurrently with data copied off to another tape drive. The net effect is that co-location and reclamation is an extremely intensive process and time consuming and will requrie significant infrastructure to support it.

The CommVault Synthetic Full also reduces the I/O load on the client machine by eliminating full backups after the first full is successfully done. In addition, like TSM it provides a way to create a new full image of the client machine using an off line process which streamlines full server restores. However, unlike TSM Synthetic Fulls are focused on ensuring that data from a client or clients is written to tape media and is of the same retention. For instance incremental backups are saved to a different media set than full backups this has the benefit of ensuring efficient aging of media and enables static or orphaned data to be aged from media according to business data retention requirements. The offline process used with synthetics is typically inititated on a weekly basis and uses the CommVault index cache taken during incremental backups to recreate a new full backup tape for this client or clients over and above the synthetic full backup taken at previous points in the past. This method fundamentally reduces the amount of infrastructure required to manage media and the time taken and yet still enables the client to only provide incremental backups to the media servers and the media servers maintain an image in cache of what the file system would contain at any point within retention. Also, the latest file or files, specific versions and an entire file system recovery to a point in time are all possible.
 
Last edited:
PREDATAR Control23

Collinos,

You must be a CommVault guy - an end user or a Technical/Sales rep! Welcome to our forum! I have been trained on CommVault as well, but with all respect, I still am biased to TSM.

I see the light of some of the CommVault logic but I am not totally convinced that the backup scheme is better than what TSM has.

Yesterday, I was briefing some folks in my workplace about TSM - believe me when I say that they are CommVault guys - and a few of them saw the "light" of TSM - more logical and straightforward. Just too bad that TSM is licensed by core.

Again, welcome to our forum.
 
PREDATAR Control23

A little more detail to add to the mix...

- We will be storing 30 versions(days) of files on disk for onsite regardless of the product we choose
- The only thing being written to tape is the offsite copy

Does this change the process at all from a TSM or Commvault viewpoint?
 
PREDATAR Control23

Bear in mind that version retention in TSM is very different the way CommVault does it using their so called synthetic backup. The way I understood it, if you intend to keep these many versions using CommVault you will end up using more tapes. I am not sure if this is easy to do using CommVault.

If you intend to keep thirty versions of any file online, remember that 30 versions of the same file would also exists off site if you do a true off site backup.

I believe in this scenario, TSM would answer your needs better.
 
Last edited:
PREDATAR Control23

The more I think about it...if I'm keeping 30 versions(days) on disk, I should have little issue with full restores unless the full restore is needed from something older than those 30 days(very rare).

Please correct me if I'm wrong.

Collinos, any thoughts on SIS? We're banking on that working as advertised even though its version 1.0. Have any personal experience with it and its real-world performance?
 
Last edited:
PREDATAR Control23

I have to ask whether 30x versions of the same document are your actual requirements... if so, buy TSM. However, if you have a more normal requirement to hold data against business retention requriements i.e. 30x days for user group 1, 60x days for group 2 with both user group 1 and 2 having archive copies sent to tape media in an encrypted format and held offiste for extended retntetion (say 1x year as an example) then it would be CommVault Galaxy every time.

Single instanced storage is indeed version 1.0 of this technology. However, I have checked out the output of the technology and run a few scenarios. It maintains the same data structure as before when writing to media and also the same index structure as before also. The only new pieces added are the MD5 hashing algorithm (tried and tested all over the place and not new) and single instance database (usual btrieve type thing... again not new). So, the integration is new but not the pieces.

From my testing, there is no real improvement to the actual size of an incremental backup. Incrementals are typically new files. However, the big difference is to the size of each full backup. Galaxy takes normal or synthetic full backups and maintains links to objects already held in the SIS DB. From testing on my small rig I was finding a 6x improvement in the number of full backups I can actually hold on my disk library before the dynamic disk aging process kicked in and started pruning data.

So, important points... synthetic Full can be configured with storage policies to protect clients against specific business data retention requirements to ensure you hold data only for as long as the business wants it with the clients only ever sending incremental changes over the wire. SIS on the storage policy then comes to play to make sure that the disk library then only holds new objects with references placed securely in the SIS DB for all existing objects with same hash.

Finally, other features like End USer Search (Utilising FAST content indexing), GridStor (failover paths and loadbalancing of Media Agents), encryption of the vaulted copy to tape (ASE, Blowfish, 3DES etc) and extensive reporting capabilities should also be seriously considered as they will reduce amount of time to find data, the media usage through efficient tape sharing, remove unplanned data protection outage and have a real effect to the man hours taken to manage the environment. These features with SIS and Synthetic Full are more than a match to the next best vendor within this space (Which according to Gartner is Netbackup and not TSM).
 
PREDATAR Control23

Having some experience with CommVault I can attest to the easy management part of the suite. Even though you would probably need more Media Agents to move the data, a single management environment scales very far indeed and load balancing across data movers is done automatically so managing that part is easy. Big bulky server vs. small lightweight cost servers - seems an ongoing IT discussion.

Yet when you have multiple larger sites, CommVault does rapporting and management across all environments - has TSM got similar capability? I'm just not sure.

Just trying to understand something: yes, TSM does incremental forever, so no fulls. But you cannot guarantee the existence of a dataset at a point in time? (only file versions) Doesn't that work against SLA type questions like - I want to keep data on disk 1-2 Months? Collocation in that sense is just a patch to help work against fragmentation, while taking up a whole lot of hardware resources.

CommVault can de synthetic fulls (which essentially is incremental forever as far as the client server is concerned). But would require you to schedule fulls now and again to make sure interdependence of jobs do not go back too far in time. (I would imagine TSM to have the same sort of problem, but apparently not)

I do not think TSM has any real DR tools, except help/guidelines documents and scripts. CommVault has really only 1 central database to recover, which the entire suite is geared towards recovering (multiple DR sets, really lean to recover).

But again this is only the CommVault part of the story, while most users here seem adamantly set on TSM. Until an admin comes along with intricate experience on both sides of the field - I would take comments with a grain (bag) of salt.
 
PREDATAR Control23

I'll do my best to answer with the knowledge I do have and hope someone else chimes in to fill in the blanks and/or correct me.

TSM can manage/report on multiple sites/servers quite gracefully with the ISC web console.

With TSM, the incremental forever is exactly that...only backing up what has changed...file versions vs. days. Totally different concept. With Commvault, when you do a synthetic full once a week and a regular full every third week or whatever you choose, you are still backing up a lot of the same files over and over(and a lot more tape burned).

So if you had to do a recovery as long as it fits in the 30 version(days) window...you'll have every file you need to do the restore from any of those 30 days(versions).

The DRing of TSM is actually much simpler in my opinion...there is one database and one server...the database can be replicated to another TSM server continuously, plus no additional licenses required...you can have as many TSM servers as you want as long as you license your nodes.


Side note, how does SIS work in a DR scenario...does the data get SIS'ed first at your primary disk location and then synchronized to your alternate site so its using the same amount of disk as at your primary site? And does the DR license cover SIS?
 
PREDATAR Control23

Sorry for digging this one out again after such a long time - but we're about to swallow a shop that actually uses Commvault (some 100TB "occupancy" and running a simple 30day protection scheme). Management will decide to replace this with TSM but it looks like we haven't got the time this year to run the project. In the meantime our beancounters absolutely insist that deleted files will be kept for a year in order to fulfill at least the most basic service levels we agreed on. In TSM the retonly is set to 365 and the additional capacity required is exactly the amount of deleted files minus compression, which is peanuts compared to the overall capacity. For Commvault things don't seem to be that easy. We asked them repeatedly, how this pretty vanilla business requirement could be achieved and all we ever got where utterly pointless discussions about why on earth we would need that. I'm beginning to suspect they simply can't do it.

PJ
 
PREDATAR Control23

StorageMonkeys.com has the same question posted...

I know nothing about the site but I thought it was a little odd that a different site would have the identical question on it.

Just my two cents- you can't beat the reporting you get from Commvault which is very granular and customizable. We use it only for our legacy Novell servers and it works great but eveything else uses TSM.
 
Top