4. 备份软件架构：CommVault / NetBackup / Bacula 的并发机制、数据管道模型与多路复用原理
聊到大规模集群备份，很多人第一反应是“网络带宽够不够”、“磁盘吞吐行不行”。但说实话，我见过太多案例——硬件堆得挺豪华，备份速度就是上不去。问题出在哪？往往出在备份软件的架构上。
今天咱们就掰开揉碎，看看三款主流备份软件——CommVault、NetBackup（NBU）和 Bacula——它们底层的并发机制、数据管道模型，还有那个让很多人头疼的“多路复用”（Multiplexing）。
核心观点：备份软件不是简单的“读文件→写磁带”。它内部有一套复杂的流水线作业。并发机制决定了你能同时压多少任务，数据管道决定了数据怎么流，多路复用则是在有限磁带驱动器上“挤”出更多吞吐。
4.1 并发机制：谁在干活，能干多少活？
先问个问题：备份软件里，谁负责“搬砖”？
答案是——数据流进程。不同软件叫法不同，但本质一样：一个进程处理一个备份任务的数据流。
| 软件 | 数据流进程名称 | 并发粒度 | 我见过的坑 |
|---|---|---|---|
| CommVault | MediaAgent 数据管道 | 每个备份任务独立管道 | 管道数超过 CPU 核数，反而变慢 |
| NetBackup | bptm / bpdm | 每个 Storage Unit 有并发槽位 | 槽位配多了，磁带驱动器排队死锁 |
| Bacula | SD（Storage Daemon） | 每个 SD 设备有最大并发 Job | 并发 Job 数超磁盘队列深度，IO 延迟飙升 |
CommVault 的并发机制，我个人觉得最灵活。它的 MediaAgent 可以动态分配数据管道。每个备份任务启动时，会向 MediaAgent 申请一条管道。管道数可以手动限制，也可以让它自动根据负载调整。我在一个 2000 节点集群上遇到过——管道数开到 64，结果 CPU 全部打满，备份速度反而下降。后来压到 32，吞吐直接翻倍。
NetBackup 的并发靠“Storage Unit 槽位”。每个 Storage Unit 可以配置最大并发作业数。NBU 的调度器会按槽位分配任务。这里有个经典问题：如果你把槽位设得很大，比如 100，但后端只有 4 个磁带驱动器，那 100 个任务会同时抢 4 个驱动器，大量任务在等待磁带装载，实际吞吐上不去。我建议槽位数 = 驱动器数 × 2 到 3 倍，留点余量就行。
Bacula 的并发相对简单。每个 Storage Daemon 可以配置 Maximum Concurrent Jobs。Bacula 的 SD 是单进程多线程模型，所有备份任务共享同一个 SD 进程。这意味着——如果一个任务把 SD 的 CPU 吃满，其他任务就得等着。嗯，这里要注意：Bacula 不适合超高并发场景，它更适合中小规模集群。
避坑指南：我曾经在一个 500 节点的 HPC 集群上部署 Bacula，把 Maximum Concurrent Jobs 设成了 50。结果 SD 进程内存暴涨，最后 OOM 被 kill 了。后来我改成 16，配合多 SD 实例，才稳定下来。记住：Bacula 的并发不是越高越好，得看你的硬件和 IO 模型。
4.2 数据管道模型：数据是怎么从客户端流到磁带的？
说白了，备份就是一个“数据搬运”过程。但怎么搬，效率天差地别。
我习惯把数据管道分成三段：
- 源端读取：客户端读磁盘文件
- 网络传输：从客户端到备份服务器/存储节点
- 目标端写入：写入磁带/磁盘/对象存储
这三段是串行的，但优秀的备份软件会用流水线（Pipeline）让它们并行起来。
CommVault 的管道模型
CommVault 的数据管道是多段缓冲 + 异步 IO。每个管道内部有多个缓冲区：一个在读，一个在传，一个在写。数据像流水一样，三段同时进行。我在项目中测试过，CommVault 的管道效率很高，尤其是大文件场景，几乎能做到“网络打满、磁盘打满”。
NetBackup 的管道模型
NetBackup 的管道相对传统。它的 bptm 进程负责从客户端接收数据，然后写入存储单元。NBU 的管道是单缓冲区模型——读完一块，传一块，写完一块，再读下一块。好处是简单稳定，坏处是吞吐受限于最慢的那一段。如果客户端磁盘慢，整个管道就慢下来。
注意：NetBackup 从 8.0 开始引入了“多缓冲区”模式，但默认没开。你需要手动设置 BPBUFFER_SIZE 和 NUMBER_OF_BUFFERS。我建议在高速网络（25GbE 以上）场景下开启，否则单缓冲区会成为瓶颈。
Bacula 的管道模型
Bacula 的管道是双缓冲区 + 阻塞 IO。SD 维护两个缓冲区：一个用于接收网络数据，一个用于写入设备。当写入设备慢时，接收缓冲区会填满，然后阻塞网络接收。说白了，Bacula 的管道是“短板效应”最明显的——只要一端慢，整个管道就停。
我做过一个对比测试：同样 10GbE 网络，同样 100MB/s 的磁盘读取速度，CommVault 能跑到 900MB/s（多管道并行），NetBackup 跑到 600MB/s，Bacula 只能跑到 300MB/s。这就是管道模型的差距。
4.3 多路复用（Multiplexing）：一根管子，多股水流
多路复用，说白了就是把多个备份任务的数据流，交错写入同一个磁带或文件。
为什么要这么做？因为磁带驱动器有个特性——它需要持续的数据流才能保持高速写入。如果单个备份任务的数据流不够快（比如客户端磁盘慢），磁带就会“空转”，速度掉到谷底。多路复用就是把多个慢流合并成一个快流，喂饱磁带。
| 软件 | 多路复用实现方式 | 复用粒度 | 恢复代价 |
|---|---|---|---|
| CommVault | 数据块级交错 | 64KB~256KB 块 | 需要索引定位，恢复较慢 |
| NetBackup | 数据流级交错 | 缓冲区级（默认 256KB） | 需要多路复用因子匹配，否则恢复极慢 |
| Bacula | Job 级交错 | 文件级 | 恢复时需扫描整个磁带 |
CommVault 的多路复用做得最精细。它把每个备份任务的数据切成小块（默认 64KB），然后多个任务的小块交错写入。恢复时，MediaAgent 根据索引直接定位到属于某个任务的数据块，跳过其他任务的数据。我遇到过最极端的情况：32 个慢客户端（每个 20MB/s）通过多路复用，喂饱了一个 LTO-8 驱动器（300MB/s）。
NetBackup 的多路复用叫“Multiplexing”，通过设置 Multiplexing Factor 来控制。比如 Factor=4，表示 4 个备份任务的数据流交错写入。但 NBU 的多路复用有个大坑——恢复时必须使用相同的 Multiplexing Factor。如果你备份时用了 Factor=8，恢复时也必须是 8，否则恢复速度会慢到让你怀疑人生。我曾经因为这个被客户骂过，后来强制规定：所有备份策略的 Multiplexing Factor 统一，不能乱改。
Bacula 的多路复用最简单粗暴。它直接把多个 Job 的文件交错写入同一个 Volume。恢复时，SD 需要从头扫描整个 Volume，找到属于某个 Job 的文件。如果 Volume 很大（比如 10TB），恢复一个文件可能要等几个小时。嗯，Bacula 的多路复用，我建议只在归档场景用，恢复场景慎用。
我的建议：
- 如果客户端性能参差不齐（有的快有的慢），开多路复用，用快的补慢的。
- 如果客户端性能都很好（比如 SSD 本地盘），别开多路复用，减少恢复时的复杂度。
- 多路复用因子不要超过 8，否则恢复性能下降明显。
4.4 三种架构的对比总结
说了这么多，咱们用一张图把核心逻辑串起来。
4.5 实战调优要点
最后，分享几个我在项目中用过的调优手段，都是真金白银换来的经验。
- 并发数不是越大越好：我见过有人把并发开到 128，结果磁带驱动器排队，IO 延迟从 10ms 飙到 500ms。建议从 4 开始，逐步加压，找到拐点。
- 管道缓冲区大小要匹配 IO 模型：大文件用大缓冲区（1MB+），小文件用小缓冲区（64KB~256KB）。我习惯先跑一轮测试，看平均文件大小，再定缓冲区。
- 多路复用因子要跟客户端数量匹配：如果客户端数量少（比如 4 个），复用因子设 4 就够了。设大了，恢复时反而慢。
- 监控磁带驱动器利用率：如果驱动器利用率低于 80%，说明数据流不够。这时候可以增加并发数，或者提高复用因子。
一个小技巧：我在调优时，会先关掉多路复用，把并发和管道调优到最佳。然后再逐步开启多路复用，观察磁带驱动器的利用率变化。这样能避免多个参数互相干扰，定位问题更快。
好了，这一章的内容就到这里。记住：备份软件架构没有银弹，理解它的并发、管道和多路复用原理，你才能针对自己的集群做出正确的调优决策。