* Scalable - if you need to manage a huge amount of data, TSM does it well. Where many products may take a stack of media servers, TSM can do it all from the primary server. TSM still supports media relay servers, and command routing between multiple TSM servers.
* Incrementals forever / aka synthetic fulls - Reduces the data sent between the client and the server
* SQL Database for metadata - You can query the metadata with select statements for reporting or diagnostics.
* Web resources - TSM / ADSM has been around a LONG time, so there are a lot of web resources
* HSM - TSM has support for overlaying on top of a filesystem, allowing cold files to migrate onto slower, higher density, lower cost media, while still being transparently available from the filesystem.
* Powerful CLI - the CLI has built in help, and is the primary way admins run TSM.
* Supports most common platforms (AIX, Linux, Windows, VMWare, Hyper-V, NDMP, Exchange, Domino, MSSQL, Oracle, etc etc etc.
* Integrates with snapshots for major storage providers.
* Unified pricing - some of the pricing models are fairly simple and include all of the subproducts that are actually made by IBM.
* Very complex - Even in support, which is like accelerated admin and troubleshooting training, it takes 6 months to be able to help people with the product without having a senior tech sit with you. It takes years to become a "good" resource. It takes a decade or more to become an Expert.
* High overhead - You cannot just set it up and leave it alone. You will touch TSM every day. If you are even slightly resource constrained, you will manually work on TSM for several hours per day. Basically, deploy at 25%. Plan for upgrades at 50%. Deploy the upgrades at 75% to bring you back down to 25%. If you hit 80%, you'll touch the server for a few hours per day. If you hit 90%, you will be logged in to the server all day, every day, and you may have occasional backup failures. If you hit 95%, you will hit 100%, and everything will grind to a halt.
* Negative retention policy - While it is VERY flexible, this confuses many people. To work around this means bypassing the incremental forever.
* Reclamation - With incremental backups defragmenting tape space takes a lot of time.
* Lock contention - Admin processes and client processes fight with eachother, no matter how well you time things.
* Rolling bugs - There's no such thing as a "stable" release. Base levels have new features, and huge amounts of bugs. Patch levels fix bugs, but often, they are not fixed until several major releases later. It's more like beta code is alpha code; release code is beta code; and final patch levels are semi-stable / frozen.
* Deduplication scalability - this is about the same as with any other backup product. If you have a pool larger than about 60TB raw, then you will not be able to manage some of your daily operations. Deduplication is stored in sequential file volumes, which have to be defragmented by rewriting them completely.
* Deduplication Ration - Dedupe reductions are about half that of Dilligent / ProtecTier.
* Deduplication performance - Raw performance on dedupe under the best hardware is equivalent to Dilligent's performance from 7 years ago with the DD4 nodes. Because of this, making secondary offsite copies is slower than minimum tape streaming speed. The suggested solution on the forums is that they'll drop support for offsite tape copies in dedupe, rather than allowing multiple threads to write to the same tape at the same time (interleaved).
* Not everything is internal - Several clients are made by different vendors, and rebranded, such as HSM for Windows (which does not use the space management structures in TSM - it uses archives), Sharepoint (DocAve with its own server, then a tie-in to TSM), Christie (rather than a simple GUI for building ASR media), etc.
* Many clients are fairly complex - Especially TSM for Virtual Environments (VMWare, Hyper-V) uses the normal backup/archive client for some pieces, plus separate components for Web admin, scheduling, etc. Instant Restore is yet another piece, that while VERY nice, was grabbed from a third party product, Files-X, and slapped on as-is with its own, separate style of GUI.
* Incomplete support - Xen and KVM are not supported. Platform support comes and goes. Support is not stable. It seems more about chasing version numbers and new marketing directions than unifying and stabilizing what's there.
* Internal scripting is very limited. You cannot set internal variables except a boolean return code. You cannot send emails. You cannot call external programs other than building a client schedule from inside the script. You cannot query process numbers and kill them off. Some internal commands support time limits, while others do not.
* GUI disparity. Every single piece has a different GUI. Some are websphere. Some are Java. Some are executables. Many do not integrate together. There is no common look and feel. There is no common syntax between commands and output. Text windows are not scalable. There is no overarching GUI to manage multiple TSM servers from the same place. Basically, TSM is really 20+ separate products. Long-time admins consider "TSM" to be the server command line. Everything else is an add-on.
* Server GUI - This has been replaced several times, and each time is more complex, with less functionality. Originally was a 3MB Windows executable called "DSMADM.EXE". This was great for long past when it was discontinued. This was replaced with an internal webserver that was fairly decent through version 4 and 5 of TSM, but also was discontinued. The replacement was "Admin Center", a multi-gigabyte websphere deployment, with container frameworks, horrible layout, and took many revisions to get the functionality added back in. In version 6, this was also discontinued and is being replaced with Operation Center aka Command Center. This is also Websphere, but with a better usability/design. Unfortunately, only about 10% of the daily admin tools are part of this after 5 years. It's still mostly a reporting/dashboard tool, though some new functions are being added to it periodically.
* DB2 bloat - TSM used to have an internal fork of DB2. Support and skillset for this became difficult, and scalability was limited for about 0.5% of the customer base. This was pulled out in TSM 6, and normal DB2 was deployed. That caused a 250% bloat for the same data, as well as dealing with interoperability and/or new-DB2 bugs in every release.
* Product renames every decade. This was WDSF/VM originally. In the early 1990s, it became ADSM. In the early 2000s it became TSM. In the late 2010s, it became ITSM. In the mid 2010s, it became "Spectrum Protect". With all of the changes, chunks of the code retain the old name, so there are still references to ADSM and command names are DSM. It's been owned by Adstar, Tivoli, and IBM, back and forth several times.
* Reporting is completely external, kludgy, and requires more effort than simply doing your own SQL queries into your own database. This still relies on Admin Center, which also is klunky. The best reporting was a query tool called Operational Reporter, that was about 60 megs. If it had a database, and graphs, it would have been 100% better, but instead, someone got a bonus check to ditch that and stuff in a websphere portal.
* Support is usually overloaded - It's been call-back only for a decade, and is moving to web-only. You'll spend a lot of time working your way up from someone who can barely spell TSM (Receive Call / call routing), to someone who can kind of search a database (Level 1), to someone with decent skill (Senior tech or Backend), to someone with specialization in one part (Level 2). If you don't have a system down, or major business impact, and you haven't gotten a critical situation / complaint manager involved, it may take weeks to get resolution. If there's a defect, it may take months for a fix unless it affects a large number of customers, or a customer with multi-million dollar contracts.
* Complex pricing - There are multiple options (by CPU is with weighted factors rather than anything definitive like MIPS or benchmarks), by front end storage, back end storage, factors for dedupe or non-dedupe, etc. Granted, most enterprise products have complex pricing. Just look at the CommVault sheet and see how many line items are required. At least TSM lets you go with a few different "Unified" pricing options.
* If you need to manage a huge amount of data, and like tape, then get TSM.
* If you need a great GUI, and have a big equipment budget, then get CommVault.
* If you are a small, VMWare only shop, then get VEEAM, not TSM.
* If you need small to medium dedupe, pick the product you like best. Most products can do it, and most of them have similar limitations. There are benefits of doing dedupe inside the backup product (simplicity and efficiency of replication).
* If you need giant dedupe, ProtecTier is the only way to go, no matter what Backup/DR solution you use.
* There are also places for Avamar (integration with DataDomain or VMWare).
* NetBackup, Legato, and most other enterprise solutions are good if that's what your people know, and they start small better, but otherwise are "meh" for scalability.
* If you're looking for free, you need an expert systems engineer, not just an admin. Assessing, setting up, and scaling is more complicated, but many shops make this work.
This is best for Medium to large footprint disaster recovery. If you want a small system, TSM is only good for you if you're already a TSM expert. Otherwise, the personnel costs are too high.
For Business Continuity, this can be a major component, but there's still snapshots, RTO/RPO planning, etc that are outside of TSM (but part of Tivoli / Spectrum).