我们现在备份环境乱了，我想重新设计一下。

搞这么多套备份环境做什么？测试和生产分开还可以理解，生产就不用两套了吧！既然架构都是一样的，不如整合一下，生产都用一套TSM，版本统一一下，第一备份介质都备份至虚拟带库，物理带库作为磁带出库使用！这样整个架构就干净很多了，且工作量也不算很大，风险可控！仅供参考！

这个理解，估计是兼容性导致的。比如sap的系统和erp版本都特别老，新版的tsm不支持。但是新的exchange或vmware插件需要tsm的最新版才能支持，最后缝缝补补就成这样了。

这个如果应用的各自版本不能随便升级做统一，只能小范围的优化了。将各种应用模块的版本和预期升级等信息梳理一遍。然后将tsm备份环境分类，一个是老版本的，一个是新版本的。 至于d2d2t还是怎么样，看你们规划了。反正虚拟带库也方便多分几个，3584也支持逻辑带库

最好能描述一下备份环境发展的过程，或者这个架构搭建的考虑，如果要合并又有哪方面的考虑，结合这些问题才可以做到有的放矢。

TSM 是否因为节点数量太多不易管理而分为两个套生产环境，还是处于不同网段导致，这个是很大一部分问题。还是其他问题

分开有分开的优点，合并有合并的优点，如何考虑还是要综合考虑一下。

但是最好还是尽量统一版本进行管理，相对问题较少。

合并：

1）统一版本，维护少量客户端和server 端版本

2）如果虚拟带库容量够，可以做前端第1层，后端接物理带库（第二层）用于出库，归档大部分不经常访问的数据。

3）虚拟机带库需要相对多的driver设置，在不影响性能的前提下适当多初始化driver，以满足多个备份窗口并发使用

4）个别特殊的需求可以考虑独立备份环境或其他方法解决。

如果你的两套环境没有物理隔离，建议使用统一的备份系统，避免管理的复杂度和资源的浪费。

推进总有困难，还有先别急着下定论说老版本不支持，poc测试做做，有些官方宣称不支持，其实都是能用的！至于老版本os的问题，这个就要想办法去升级，不升级只能等死，长痛不如短痛！