我的问题是…在NetBackup中build议使用什么样的多路复用因子？您是否将1Gb / spipe理networking上的Oracle RMAN备份用于LTO3？
JB
背景：
有了像NetBackup这样的企业备份工具，就有了多路复用的概念，即将多个备份客户端的数据同时进行组合，以便尽可能快地支持现代高速磁带机。
同时交织的客户数据stream的数量由复用因子决定。 复用因子越高，提供给磁带机的数据就越多，但恢复速度越慢。
由于整体恢复速度主要取决于（logging事件，确定磁带是否可用，从非现场，负载，库存等调用）比实际的磁带恢复速度，我觉得有信心使用高因素的文件系统备份。
大型数据集的Oracle备份（更经常地还原在一起）对文件系统备份构成了不同的挑战。
首先要检查的是服务器可以处理多lessnetworking（TCP）吞吐量。 使用netcat等。如果小于30 MB / s左右，从networking复用对你来说是没有用的，我的进一步build议可以忽略不计。 努力调整您的networking吞吐量。 现在，重点。
与任何其他线性磁带驱动器一样，LTO3驱动器只有在获得具有一定恒定吞吐量的数据stream时才能正常工作。
磁带在高速下通过磁头，你不想停下来。 在每次停车时，变频器必须执行冗长的程序：减速到完全停止，加速返回，通过数据终点，再次减速，加速到达数据终点。 当数据不被NetBackup快速传输时，缓冲区会频繁地溢出，所以驱动器必须频繁地停止/后退/启动。 performance受到极大的伤害。 这叫做“启停”操作或“擦鞋”。
驱动器调整磁带的速度有点，但不是很多，它可以下降到最大速度的50％左右。
Netbackup多路复用的重点在于提供更好的数据stream吞吐量并避免启停操作。 检查您的RMAN备份的吞吐量，如果它是30 MB / s或更less，您有一个经典的启停操作。
现在让我清楚一点。 如果您没有启动，我不build议多路复用RMAN备份。 RMAN非常复杂，没有多路复用。 我不想混淆RMAN，我希望我的恢复尽可能地快速，简单和无缝。
但是，如果您发现您的备份吞吐量低得令人无法接受，那么我会build议为初学者实施三个多路复用stream。 每晚增加数量，直到你不会获得更多的吞吐量。 并确保每个stream都来自不同的磁盘主轴。 不是来自不同的分区/表空间/文件系统/数据库/服务器/ LUN /其他虚拟化层。 这些问题很less，如果有的话。 物理磁盘轴。 如果你从同一个锭子喂养许多stream，你只会造成颠簸，整体性能将下降更多。
注意：NetBackup理论上也可以解复用还原。 如果我没有记错的话，在恢复之前会暂停一点，以便有更多恢复尝试的机会。 在这种情况下，它们将像多路复用备份一样运行。 但是请用手册来validation，我只有90％肯定这个。
这完全取决于您的oracle服务器是否可以快速移动数据以保持LTO3驱动器的stream式传输。 我不会复用Oracle数据，因为大文件的传输速度足够快，从而使驱动器以可接受的速度运行。
然而，在我们更换了Oracle服务器之前，他们只支持了目前速度的一半，但实际上我已经将它们复用了。
值得注意的是，与NetBackup复用时恢复速度稍慢，但速度并不慢。 我知道certian你可以解复用恢复。 我们一直都在做恢复testing，偶尔也要replace掉丢失的数据。
我强烈build议两种方式进行testing，看看您是否可以保持LTO3硬盘足够快地移动而不需要多路复用。
我发现解决这个问题最简单的方法是将初始备份写入磁盘，然后将备份映像复制到磁带。
多路复用备份更有可能跨越磁带，更难以导入或使用外部的netbackup，恢复较慢，是一个全面的丑陋的黑客创build防止擦鞋磁带。
Netbackup具有非常好的直接到磁盘的function，CLI工具可以很容易地编写图像复制机制。