A couple of posts ago I wrote about the need for economies of scale in backup, and lamented (or ranted, to put it bluntly) about the lack of such economies in currently available backup solutions.
Before I go further, let me be clear: the requirement, in my opinion, is for solutions that offer genuine economies of scale. That is, declining marginal costs. This is very different than reducing costs. I think we have done OK as an industry at reducing costs.
If you look at the cost of backup with just tape, and compare that to the cost of backup with source or target deduplication, I don't think there is any doubt at all that you can reduce the cost of backup by employing deduplication--either to augment or complement tape, or to move to a tapeless environment. Your ability to reduce costs is even better if you archive too--every MB that you archive is a MB you don't have to back up.
So, having said all that, I found it interesting that Tony Pearson over at IBM took my post not as an opportunity to discuss backup, recovery and archiving solutions and cost reduction, but to claim that "IBM has Scalable Backup Solutions."
(But so what? And way to miss the point entirely!)
Most everybody has scaleable solutions in the sense described by Tony. Everybody can keep adding component pieces to scale up their backup infrastructure.
The problem with Tony's thesis however is that with TSM, for example, you need to add those component pieces faster than you do with other backup architectures. And the component pieces are relatively more expensive than they are with other competitive backup software. TSM, generally speaking, is the worst backup application of all major backup applications when it comes to scaling in a cost effective manner.
And I say that with all due love and respect for TSM's functionality and capabilities. But as an architecture, it is horrible when it comes to scaling. Ask a large TSM customer how many TSM servers they have. I can guarantee that number will be 5 to 10 times as many as they would have if they were a NetBackup or NetWorker customer.
Why is this? TSM has no real concept of a media server or storage node--in other words, no real way to scale horizontally without growing the number of master servers. (Technically there is such a capability, but for whatever reason it is never used in the real world...) TSM requires significant amounts of disk for the master servers--due to the database and disk storage pool design--again in contrast to the competitive alternatives. TSM puts an enormous load on TSM masters--ingest, migration, reclamation, duplication, and so on. All this adds up to the fact that if you use TSM, you will absolutely have more servers, bigger servers, more expensive servers, and more (disk) storage attached to them to accomplish the same job as you would have with either NetBackup or NetWorker.
And not just a little more. A lot more.
So does TSM scale? Sure! Just add more servers. But this is not an economy of scale. Nothing gets less expensive as the capacity grows. You get a more or less linear growth of costs that is directly correlated to the growth of primary storage capacity. (Technically, it costs will jump at regular and predictable intervals, by regular and predictable and equal amounts, as you add TSM servers to the infrastructure--but on average it is a direct linear growth. Assuming you are right sized right now, if you were to double your primary storage capacity, you would double the size of the TSM infrastructure, and double your associated costs.)
But it gets worse: nothing that TSM does from a deduplication point of view does anything to change this. TSM deduplication may reduce (somewhat, but a lot less than you would think and a lot less than with any of the alternatives) the amount of back end storage capacity required. Again however, it does not result in any economies of scale. Just because you reduced your capacity by 25% (and cost) does not mean you have achieved economies of scale. It just means you have reduced your costs. If you double the size of your primary storage, the cost of backup will still double (it will just be 25% less than before).
Unfortunately, we can say exactly the same things about the ProtectTIER appliance that Tony notes. It does not achieve economies of scale. It may reduce some costs for TSM users in a small way, but you will still have a linear relationship between amount of primary storage, and the cost of backup infrastructure. (A little lower than tape maybe, but still linear.)
So... not only does IBM not have backup solutions that achieve economies of scale (my original ask), but their backup solutions tend to scale poorly relative to their competitors. Which is maybe not something that Tony should be drawing attention to...
P.S. None of this should be taken as a comment on the quality of TSM, or its ability to back up a large enterprise environment with a wide range of applications, platforms, and challenges. I am (mostly) confident that TSM can do the job of backup. It is a question of scale and complexity. How well does it scale to meet these challenges? How complex is it? How difficult to manage? How many components do you end up with to meet the challenges? Are there any fundamental architectural issues? The answers to these questions do not detract from TSM's ability to do backup. The answers do, however, impact the TCO of TSM. And even if you don't care a lot about TSM scalability right now (if you have a relatively small amount of primary storage) it is probably something you should think about if you are going to grow: will TSM scale cost effectively to keep up with that growth.
P.P.S The answers to the questions are: not well, very, somewhat, too many, and yes! (a few big ones), respectively.