我的问题是... 对于通过 1Gb/s 管理网络到 LTO3 的 Oracle RMAN 备份，建议使用/是否使用 NetBackup 中的哪种多路复用因子？
JB
背景：
在 NetBackup 等企业备份工具中，有多路复用的概念，即将来自多个备份客户端的数据同时合并，以便尽快将数据传送到现代高速磁带驱动器。
同时交错的客户端数据流数量由复用因子决定。复用因子越高，输入磁带驱动器的数据越多，但恢复速度越慢。
由于整体恢复速度主要由混乱（日志事件、确定磁带是否可用、从异地调用、加载、库存等）而不是实际的磁带恢复速度决定，因此我有信心使用高系数进行文件系统备份。
包含大型数据集的 Oracle 备份（通常会一起恢复）对文件系统备份提出了不同的挑战。
答案1
首先要检查的是您的服务器可以处理多少网络（TCP）吞吐量。使用 netcat 等。如果低于 30 MB/s，则网络多路复用对您没有用，我的进一步建议可以忽略。而是努力调整您的网络吞吐量。现在，进入正题。
LTO3 驱动器与任何其他线性磁带驱动器一样，只有在获得具有一定恒定吞吐量的数据流时才能正常工作。
磁带正高速通过磁头下方，您不想让它停下来。每次停止时，驱动器都必须执行冗长的过程：减速至完全停止，加速返回，通过数据结束点，再次减速，加速到达数据结束点。当 NetBackup 无法足够快地输入数据时，缓冲区会频繁不足，因此驱动器必须频繁停止/倒带/启动。性能会受到严重损害。这称为“启动-停止”操作或“擦鞋”。
驱动器会稍微调整磁带的速度，但幅度不会很大，它可以降至最大速度的约 50%。
Netbackup 多路复用的全部目的是提供更好的流式吞吐量并避免启动-停止操作。检查 RMAN 备份的吞吐量，如果它为 30 MB/s 或更低，则说明存在典型的启动-停止操作。
现在，让我澄清一件事。如果你不要有开始停止我会不是完全不推荐多路复用 RMAN 备份。RMAN 已经足够复杂，无需多路复用。我不想与 RMAN 纠缠不清，我希望我的恢复尽可能快速、简单和无缝。
但是，如果您发现备份吞吐量低得令人无法接受，我建议首先实施大约三个多路复用流。每晚增加数量，直到您无法获得更多吞吐量。并确保每个流来自不同的磁盘主轴。而不是来自不同的分区/表空间/文件系统/数据库/服务器/LUN/其他虚拟化层。这些无关紧要，如果有的话。物理磁盘主轴。如果您从相同的主轴提供许多流，您只会导致抖动，整体性能将进一步下降。
注意：NetBackup 理论上也可以对恢复进行解复用。如果我没记错的话，它会在恢复之前暂停一会儿，以便有机会启动更多恢复尝试。在这种情况下，它们将联合运行，就像多路复用备份一样。但请用手册验证这一点，我对这一点只有 90% 的把握。
答案2
这完全取决于您的 Oracle 服务器是否能够以足够快的速度移动数据，以保持 LTO3 驱动器的流畅运行。我不会多路复用 Oracle 数据，因为大文件的传输速度足够快，可以让驱动器以可接受的速度运行。
然而，在我们更换 Oracle 服务器之前，它们的备份速度只有当前速度的一半左右，事实上我确实对它们进行了多路复用。
值得注意的是，使用 NetBackup 多路复用时，恢复速度会稍微慢一些，但不会慢很多。我知道在恢复时可以进行解复用。我们一直这样做，既是为了进行恢复测试，也是为了在极少数情况下真正替换丢失的数据。
我强烈建议两种方式都进行测试，看看是否无需多路复用就能让您的 LTO3 驱动器保持足够快的运行速度。
答案3
我发现解决这个问题最简单的方法是将初始备份写入磁盘，然后将备份映像复制到磁带。
多路复用备份更有可能跨越磁带，更难导入或在网络备份之外使用，恢复速度更慢，并且是一种为防止擦鞋磁带而创建的丑陋的黑客行为。
Netbackup 具有非常好的直接到磁盘功能，并且 CLI 工具可以很容易地编写图像复制机制脚本。