现在觉得自己的虚拟带库像是一个宝贝一样，天天祈祷不要出问题，磁带库是不是应该准备多个？

分享下自己在BRS方向的一点经验，望各位斧正。

先解答你的这个问题，所有的备份数据都先写到VTL，然后VTL挂掉了，要恢复怎么办？

VTL是一套软件来模拟硬件工作，如果是VTL整个系统挂掉，基本GG。但相对于物理带库来讲，这种风险要大得多，物理磁带库涉及到介质（磁带）、驱动器（磁带机）、还有磁带库库体硬件。如果物理磁带库介质（磁带）出现损坏，（如果你没备份）那基本完蛋datalose。驱动器出现故障，调备件都得一段时间，如果驱动器紧张，很多备份窗口都会拉长。库体故障的话，那更加麻烦，尤其是机械手物理损坏。虚拟磁带库，在介质方面基本底层都有RAID或类RAID保护，能容忍一定程度的损坏。由于是软件系统，虚拟出的带库驱动器（磁带机）假设程序故障，也可以修复或重新配置，再不济重建一个带库把数据克隆到新带库恢复。虚拟带库的库体，出现问题最大的可能就是系统：1，软件BUG  2，系统hang。软件bug可以打补丁解决，即使无法解决导致datalose之类的问题可能性也小。系统hang是最致命的，只能拉原厂现场救急，不过这个的可能性更小。如果真是一次性坏盘四五块挂掉，为何不当天买彩票呢 ：）

综合来看，不管是单物理磁带库和单虚拟磁带库，风险都比较高，万一出现问题提心吊胆。所以做方案的时候，一般推荐PTL+VTL互备，VTL承担大部分备份，PTL承担核心备份。VTL上数据存放周期不超过三个月，所有重要的VTL轻量级数据备份完立刻PTL克隆（大数据量的备份白天克隆），（如果有能力）PTL重要数据也向VTL克隆一份保留较短周期。

这样的方案一定程度上解决了磁带库故障的问题，但衍生出另一个问题----------项目预算资金不够，怎么办？

至于你提到的第二个问题，虚拟磁带库操作繁琐。各个厂商不一样，我主要接触的是EMC datadomain系列，把磁带从虚拟磁带机上强制挪到槽位，一条命令就解决，不需要Patition Offline。磁带和磁带库的操作命令也小白化，还是比较好用的。但datadomain的重删性能，这个和备份管理员水平息息相关，高的可以10X，低的1X也有。个人感觉datadomain好用、简单，可是~贵！贵！贵！贵！贵！贵！

备份，是数据丢失的最后一根救命稻草，怎么自救，自救到什么程度，看你怎么下血本了！一分钱一分货。

带库有带库的优势，从很多监管要求上来看的话，许多金融金融需要做离线备份介质保存，因此带库是必须要要，你的这个问题可以考虑使用D2D2T，也就是磁盘到虚拟机带库再到物理带库，第一级备份设备可以考虑使用磁盘啊，如果没有监管要求的话，可以考虑使用磁盘当做后端存储，利用软件层的重删等功能，管理起来会简单不少，不用考虑带库设备的磁带，driver、机械手等问题。

我觉得虚拟带库对于有的单位  还是直接做成文件系统更直接有效 。不过 虚拟带库不卖钱卖的多吗 呵呵

这个问题很多企业也会面临到，每种方案都有相应的风险存在。那么基于这个问题我们在以下方面进行考虑。

1. 一套TSM管理多个带库（物理和VTL），当然如果非常重要的话可以考虑TSM的高可用行

    这个方案:

    1）不要所有的数据全部经过VTL，而是分开存放，需要频繁读写或恢复的且数据量不是特别大的可以考虑VTL（保存时间不要太长），数据量大，读写恢复不频繁入物理带库

    2）这样方案一套TSM，license和维护均在一套上完成，需要TSM宿主机配置高一些，且物理带库和VTL的驱动器数量一般不会成为问题。

    3）但是这样的方案如果ＴＳＭ挂掉或维护，则也会影响面比较大

所以如果面临比较大的备份作业量和备份数据量，可以考虑下面方案

２. 搭建两套TSM环境

    1）每套ＴＳＭ管理一个带库，作业数据分别入相应的带库，且相互不影响

　２) 管理两套环境,如果需要备份多份的作业可以考虑，一个备份两个node或者使用replication的实现数据存放两份

    3）如果其中一套环境识别，可以临时迁移到另一套环境进行相应的备份工作。

综上所述，还是要看企业场景和可以承担的风险和备份方面的投入。选择适合自己的方案。

个人认为，短期的备份，用作异常恢复的，用磁盘备份较好，恢复也方便，特别现在盘阵真的很便宜。

那些用作历史归档，需要长期保存的可以用磁带。

所以带库不需要太多，好用就行。

说道长期备份，那就涉及到可恢复性了，所有只有用系统命令往磁带上备份或恢复才是王道。神马备份软件永久了都会有问题，最终歇菜。

有关使用磁盘存储方式实现的方式，由于使用lanfree方式目前还不行，后续待上了万兆网络或者更高的ip网络时可以考虑大批量的使用。