Borg 这台机器配多大内存，十个人里有九个是凭直觉拍的——"备份服务器嘛，32G 够了"。我见过太多次同一个剧本：仓库从 2TB 慢慢涨到 15TB，同一台机器跑一次 borg create 从 3 分钟变成 40 分钟，内存占用从 4G 爬到 11G，最后某天夜里 OOM 被系统杀掉，备份静默失败两周没人发现，直到真要恢复数据才发现最后一个可用归档是半个月前的。
根因不在磁盘，也不在 CPU，而在仓库里到底存了多少个 chunk。Borg 的 chunks 索引是一次 create 就要整体读进内存的，chunk 总数 × 单 chunk 索引开销 ≈ 常驻内存。而 chunk 总数 = 仓库逻辑容量 ÷ 平均块大小。翻译成人话就是：你把块切得越小，去重率越高，代价是内存线性往上涨。这个反比关系，是 Borg 备份服务器选型里最容易被忽略、也最容易在半年后爆雷的一条。
磁盘这边是另一个坑，而且更隐蔽：仓库占多少盘，不等于你要买多少盘。borg prune 只打标记不释放空间，真正回收必须靠 borg compact 把 segment 重写一遍，重写过程中新老 segment 是并存的，峰值需要接近仓库大小的空闲空间。这一条在采购阶段几乎没人算进去。
先把结论摆出来，后面再展开推演：
borg check --verify-data 必须单独排窗口。它会全量读取并校验所有 segment，CPU 和磁盘 IO 一起打满，还额外吃一大块内存，别把它塞进日常备份的同一个时间片里。要算准内存和磁盘，得先搞清楚仓库在盘上到底是什么形态。很多运维把 Borg 仓库当成一个"会自动变小的目录"，这个理解从根上就错了。
Borg 的仓库（repository）本质是一个目录，里面躺着一堆编号递增的 segment 文件，默认每个 segment 大约 500MB 封顶，写满一个就开下一个。所有 chunk、归档元数据、manifest 都被追加写进这些 segment 里。
这里有个关键点：一个 segment 里往往混着多个归档的 chunk。也就是说，"删掉一个归档"和"删掉一个文件"在物理层完全不是一回事。你删的归档，它的 chunk 可能还被别的归档引用着，Borg 不敢动；就算真没人引用了，那段字节还躺在 segment 中间，Borg 也不能原地抠掉——所以只能标记，等后续重写。这就是 prune 不释放空间的物理根源。
manifest 可以理解成仓库的总目录，记录着有哪些归档、各自的时间戳和 chunk 列表。它很小，但每次操作都要读写，而且它本身也受锁保护。
Borg 的 segment 是只追加（append-only）的，create 只往末尾写，从来不回头修改已写入的字节。这个设计换来两个好处：写性能接近纯顺序写，机械盘也能跑出不错的吞吐；以及天然的抗误删——已经写进去的历史数据不会被新的写操作覆盖。
代价也有两个，正好对应本文的两个主线。一个是空间只能靠重写回收，也就是前面说的 compact 问题；另一个是元数据必须全量常驻，因为要判断一个新 chunk 是不是已经存在，就得查全量 chunks 索引，这个索引必须在内存里才跑得动。于是仓库越大、块越小，索引越大，内存越吃紧。
Borg 的去重靠 chunker（分块器）做内容定义分块，默认参数是 buzhash,19,23,21,4095。拆开看：最小块 2^19 即 512KB，块大小上限 2^23 即 8MB，中间那个 21 是掩码位数，决定平均块落在 2^21 也就是 2MB 量级，最后的 4095 是滑动窗口的字节数。
行业内常引用的经验值是：每个 chunk 在仓库索引里约占 100 字节量级的开销（含 chunk id 与引用计数）。这个数字各家实现略有出入，实际进程占用还会因为 Python 对象头和哈希表负载因子比理论值高出一截，但用来做量级推演完全够用。
我们来算三组数，用的是同一份 20TB 的逻辑备份量：
默认 2MB 平均块：20TB ÷ 2MB ≈ 1000 万个 chunk，索引开销约 1000 万 × 100B ≈ 1GB。加上进程本身的运行开销，一次 create 实测占用几个 GB 是很正常的。
把平均块压到 512KB（很多人为提高去重率会这么干）：20TB ÷ 512KB ≈ 4000 万个 chunk，索引开销直接到 4GB，实际内存占用奔着 8–12GB 去。去重率理论上更漂亮，尤其是虚拟机镜像、数据库文件这类大文件局部改动多的场景，但你换来的是内存和 create 时长的双双上涨。
反过来放大到 4MB：chunk 数降到约 500 万，索引开销回到 500MB 量级，内存压力小一半，代价是去重粒度变粗——一个 4MB 的块里只要改了一个字节，整个块就要重存一份。
所以我的判断很直接：块大小不是一个"调优项"，它是一个在采购阶段就要定死的架构决策。因为 chunker-params 一旦确定，仓库里已有的 chunk 不会因为改参数而重新切分，你想中途换块大小，基本等于要重建仓库、重跑一次全量。重建全量意味着新仓库、双倍磁盘、一次几十 TB 的传输，这些成本远比一开始多买两条内存高。
实操建议：常规文件服务器、代码仓库、日志归档，用默认参数别动；只有当你备份的主体是频繁局部改动的超大文件（VM 镜像、数据库裸文件、设计源文件），并且逻辑量在 10TB 以下时，才值得考虑把平均块往下调一档，同时把内存预算翻倍。
Borg 支持 none、lz4、zstd、zlib 四种压缩，默认档位的 zstd 大概在 3 左右。这四个怎么选，本质上是一道"CPU 换磁盘还是磁盘换 CPU"的账，而 Borg 场景里磁盘更贵——因为它还要连带影响内存（仓库越大 chunk 越多）。
lz4 的特点是快，快到压缩几乎不成为瓶颈，单核就能吃满千兆网或 SATA SSD 的顺序写。但压缩率明显低于 zstd，实测差距通常在十几个百分点到二十几个百分点之间，取决于数据类型。这个差距在 20TB 仓库上就是 4TB 左右的裸盘差异，还得再加 4TB 的 compact 临时空间。算下来，lz4 省下的那点 CPU 时间，远不够抵消多买 8TB 盘的钱。
zstd 是目前的默认推荐，理由不只是压缩率，更关键的是它可以多线程压缩。Borg 的压缩本身对多核利用并不算特别激进，但 zstd 的实现允许并行，你给它 16 核和给它 4 核，压缩段的速度差距是实打实的。备份窗口 = 传输时间 + 分块时间 + 压缩时间 + 加密时间，其中压缩这一项是可以靠堆核数硬压下去的。所以我给备份服务器配 CPU 的原则是：核数优先于主频，16 核起步，20TB 以上仓库给到 32 核。
zlib 现在基本没有理由选了——压缩率跟 zstd 差不多甚至略差，速度却慢一大截。none 只在一种情况下合理：备份的数据本身已经是不可压缩的（比如已经加密过的归档、视频素材库），这时候开压缩纯属白烧 CPU。
加密这边，Borg 默认 repokey-blake2，数据加密算法是 aes-ctr。加密是纯 CPU 活，开启后吞吐下降是必然的，在没有硬件加速的平台上，掉三到五成吞吐都不稀奇。好在现在几乎所有服务器级 x86 CPU 都带 AES-NI，硬件指令把 AES 的开销压得很低，同等条件下损失通常能控制在一个比较能接受的范围内。
这里要提醒一句容易踩的坑：不要为了省 CPU 关掉加密。备份服务器通常是内网机器，很多人觉得内网就安全了，但勒索软件恰恰是横向移动进来的。加密不仅防泄密（仓库拷走也读不了），配合 append-only 还能防篡改。真要省 CPU，正确做法是确认 CPU 支持 AES-NI，而不是把加密关掉。
这一节是全文最容易省下真金白银的部分。
很多人以为 borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 执行完，磁盘就腾出来了。不是的。prune 只做标记，不做回收。它在元数据层面决定哪些归档该留、哪些该删，被删归档独占的 chunk 会被标记为"无引用"，但那些字节仍然实实在在躺在 segment 文件里，df 看不出任何变化。
真正回收空间有两个路子。较新版本的 Borg 提供了 borg compact，它扫描所有 segment，把仍然被引用的 chunk 重新写进新的 segment，然后删掉老 segment。旧版本没有这个命令，只能用"导出归档再重建仓库"或者 borg delete 配合重建的方式，本质上也是重写一遍。
重写的代价就是临时空间。compact 执行期间，新老 segment 同时在盘上，仓库实际占用会冲到接近两倍。等重写结束、老 segment 被删除，占用才回落。这意味着：
你的仓库打算长到 20TB，那磁盘可用容量就不能只买 20TB，甚至不能只买 25TB。我建议按 100% 预留，也就是买 40TB 可用容量；预算实在紧，也不要低于 50%，即 30TB。否则你会遇到一个非常难堪的局面：compact 跑到一半盘满了，仓库停在半重写状态，既要救数据又要腾空间。
还有一条容易被忽略的选型建议：备份服务器的磁盘是顺序写为主的负载，随机 IOPS 要求并不高。所以大容量机械盘（企业级 Nearline SAS/SATA）在备份场景下性价比很高，RAID6 或 RAIDZ2 组一组，容量和安全性都不错。别把预算花在高端 NVMe 上——NVMe 的随机读优势在 Borg 这里基本用不上，同样的钱换成更大容量的机械盘，多出来的容量正好拿去当 compact 的临时空间。唯一建议上 SSD 的地方是系统盘和 Borg 的缓存目录（~/.cache/borg），那是个小随机读写的热点。
规划公式很简单：仓库容量 ≈ 首次全量去重后大小 + 每日增量 × 保留副本数，算出这个数之后再乘 1.5–2 倍作为采购容量。别忘了把 compact 的峰值算进去，这一步漏了，半年后一定补课。
borg check 有两个层级。默认只校验元数据，读 manifest 和各归档的元数据，验证结构完整性，这个比较快，日常可以随备份一起跑。
加了 --verify-data 就完全是另一回事了：它会全量读取仓库里的每一个 segment，把每个 chunk 重新算一遍哈希并比对。对一个 20TB 仓库来说，这意味着要实打实读 20TB 数据，同时全程跑哈希和解密运算，还要把 chunks 索引整体载入内存。
三项资源同时打满：CPU（哈希 + 解密）、磁盘 IO（全量顺序读）、内存（全量索引）。这个组合决定了它绝对不能和日常备份撞车——两个任务抢 IO，备份窗口翻倍；两个任务都要全量索引，内存直接翻倍，OOM 风险陡增。
时间成本也常被严重低估。20TB 仓库在机械盘上跑一次完整 --verify-data，按 150–200MB/s 的持续读取速度算，光读盘就要 30 小时往上，这还没算 CPU 校验跟不跟得上。所以校验频率必须按你的实际恢复目标来定，而不是拍脑袋"每月一次"：如果业务能接受一天的数据丢失，季度校验一次就够了；如果是核心数据库且要求 RPO 接近零，那就把仓库拆小，让单次校验能在一两个晚上跑完。
我的做法是：元数据校验跟着每次备份走（成本可接受），--verify-data 单独排在季度维护窗口，提前一周确认磁盘余量够、内存够、那一周不安排 compact。三件事——create、compact、verify-data——永远不要并行。
Borg 的仓库靠锁文件防止并发写。这不是一个可以绕过的"限制"，而是保护仓库一致性的硬机制。多个客户端同时往同一个仓库 create，会直接撞锁，表现是后发起的那个报错退出。如果你的定时任务撞在一起，就会看到随机失败的备份——这种间歇性失败最坑人，因为它看起来像网络抖动。
标准做法是一仓一源：每台需要备份的机器对应一个独立仓库。听起来浪费，其实恰恰相反——Borg 的去重是仓库内去重，不同机器的操作系统文件、公共库几乎不重复，合到一个仓库里去重收益很小，反而带来锁冲突、权限管理复杂、一个客户端被攻破连累全部备份这三个问题。
真需要多客户端汇聚（比如分支办公室往总部备份），那就用 borg serve --append-only 或者在 SSH authorized_keys 里配强制命令 command="borg serve --restrict-to-path /backup/clientA"。这两个手段是防误删和防勒索的关键：只追加模式下，客户端能写新归档，但删不了老归档；restrict-to-path 把客户端锁死在自己的目录里，看不到别人的仓库。
这里有个绕不开的两难：append-only 能防勒索，但也意味着被攻陷的客户端可以往仓库里疯狂灌垃圾数据，把磁盘写满。解法是配额加监控——给每个客户端目录设文件系统配额（XFS project quota 或者 ZFS quota 都行），并且对仓库容量增长率做告警。只做一半的安全措施是伪安全。
另外别忘了 repokey 的密钥备份。repokey 模式下密钥存在仓库里，但用 passphrase 加密，passphrase 丢了等于数据全丢。我一般会要求客户把 passphrase 和一份 borg key export 的明文密钥分开离线保存，纸质件进保险柜那种。这不是形式主义，是真有人因为重装系统丢了 passphrase，几十 TB 备份变成一堆乱码。
下面这张表按仓库规模分四档，给出内存、CPU、磁盘与临时空间的搭配思路。内存一列的推导依据就是前面那条反比关系：chunk 总数决定索引常驻内存，表里按默认 2MB 平均块估算，如果你把块调小，内存请按比例往上加。
| 仓库规模 | 内存配置 | CPU 与压缩加密 | 磁盘与临时空间 | 适用业务 |
|---|---|---|---|---|
| 1TB 级 （约 50 万 chunk） |
16GB ECC 索引约 50MB，实际占用 0.5–1GB |
8 核带 AES-NI zstd 默认档，压缩 CPU 富余 |
2×4TB 企业级盘 RAID1 compact 余量充足 |
小微企业文件服务器、官网与代码仓库异地副本 |
| 5TB 级 （约 250 万 chunk） |
32GB ECC 索引约 250MB，实际占用 2–3GB |
16 核带 AES-NI zstd 多线程，压缩不成瓶颈 |
4×6TB RAID6，可用约 12TB 约 100% 余量 |
中型团队文档与数据库逻辑备份、多站点汇聚 |
| 20TB 级 （约 1000 万 chunk） |
64–128GB ECC 索引约 1GB，实际占用 4–8GB |
32 核带 AES-NI 压缩加密并行，留足校验窗口算力 |
8×8TB RAID6，可用约 48TB compact 峰值需 ≥20TB 空闲 |
中大型企业统一备份平台、VM 镜像与归档库 |
| 100TB 级 （约 5000 万 chunk） |
256GB ECC 起步 索引约 5GB，实测占用常超 20GB |
32 核以上，双路更稳妥 建议拆分仓库降低单次索引压力 |
12×16TB RAID6 + 热备 或分布式存储，余量不低于 50% |
IDC/云服务商托管备份、长期合规留存 |
表里的配置是技术口径的选型参考，具体预估价格，以咨询为准。备份服务器的价格受盘位数量、单机盘容量、内存容量和带宽四个变量共同影响，同样标称"20TB 可用"，用 8 盘位还是 12 盘位、用 8TB 盘还是 16TB 盘，报价差距很大，所以不在这里给确定数字，避免误导。
表里有两处值得单独强调。一是 100TB 那一档，我的真实建议是别做单个 100TB 仓库，拆成 5 个 20TB 仓库更好：单次 create 的索引内存从 20GB+ 降到 5GB 上下，单次 --verify-data 从几十小时降到一晚上能跑完，某个仓库出问题也不会连累全部数据。二是 20TB 档的磁盘配置看着夸张（可用 48TB 装 20TB 仓库），这正是 compact 峰值预留——你要么现在多买盘，要么半年后半夜起来救火。
落到具体机型上，备份服务器的诉求很明确：大盘位、大内存、核数够、网络稳。下面三档是我给客户配 Borg 备份服务器时用得最多的组合。
#1 一万网络「裸金属 E5-2698v4×2 大容量存储型」——这一档是我最常推的。双路 E5-2698v4 合计 40 核，带 AES-NI，跑 zstd 多线程压缩加密完全够；内存可以按需加到 128GB 甚至 256GB，正好对应 20TB 仓库那一档；多盘位支持大容量企业级机械盘组 RAID6，容量和冗余一起解决。官网明示 ¥3999 起（以官网实时价为准），作为一台 20TB 级 Borg 备份服务器的底座，性价比很实在。物理机独享还有个隐形好处：compact 和 check 跑起来能把整机资源吃满，不用担心和邻居抢 IO。
#2 一万网络「一万云 弹性云主机」——¥25 起（以官网实时价为准），我一般不拿它当主备份仓库，而是拿来做两件事：一是异地第二副本，把本地 Borg 仓库用 borg with-lock 同步一份到云上小容量仓库（只保留近期归档），满足"两地各一份"的基本要求；二是当 SSH 跳板或监控节点，跑备份成功率的巡检脚本。它的价值在于便宜和即开即用，补位用最合适。
#3 一万网络「多节点异地备份组合（华南/华东/华北）」——Borg 走 SSH 传输，网络是备份窗口里实打实的一半。1Gbps 理论约 110MB/s 量级，实际还要扣掉 SSH 加密开销和跨地域延迟，能跑稳 70–90MB/s 就算不错了。跨地域备份时，把备份服务器放在离数据源近的节点，比盲目加带宽更管用。多节点布局的另一层意义是容灾：机房级故障时，异地那份才是能救命的。
补一句服务层面的考虑。一万网络深耕 IDC 19 年（成立于 2007 年），深圳南山总部，自营机柜最快 1 分钟上架，7×24 中文工单 5 分钟响应，硬件故障 10 分钟自动迁移——对备份服务器这种"平时没人看、出事就是大事"的设备，响应速度比机器本身的参数更重要。扩容盘位、加装内存这类需求，能当天处理掉，备份窗口才不会被拖长。另外免费的 5–20G DDoS 防护对 Borg 也有意义：备份服务器一旦被打瘫，备份链路就断了，恢复能力等于同步归零。
翻车点一：默认块大小一路用到仓库爆掉。
为什么坑：默认 2MB 平均块对大多数数据是合适的，但如果你备份的主体是 VM 镜像、数据库裸文件这类大文件，很多人会为了去重率把块调到 512KB，然后看着仓库涨到 20TB，chunk 数冲到 4000 万，一次 create 吃掉 10GB+ 内存，机器开始 OOM。
怎么避：调块大小之前先算内存预算，chunk 数翻几倍内存就备几倍。更稳的做法是先按默认参数跑三个月，用 borg info 看实际去重率和 chunk 总数，再决定要不要动参数。中途改参数等于重建仓库，成本极高。
翻车点二：prune 跑完以为空间回来了，结果磁盘写满。
为什么坑：prune 只打标记，字节还在 segment 里。运维看着 borg list 里归档确实少了，df -h 却纹丝不动，误以为命令没生效，接着重复执行 prune，白白消耗 IO。真正的空间一直没释放，直到某个深夜备份写盘失败。
怎么避：把 borg compact 排进固定维护窗口，和 prune 串成一条命令链。并且提前确认空闲盘 ≥ 仓库当前占用，这是硬门槛。旧版本没有 compact 的，就规划重建仓库的时间和双倍磁盘。
翻车点三：多个客户端共用一个仓库，备份随机失败。
为什么坑：Borg 用锁文件防并发写，两个客户端撞上就是一边报错退出。因为失败是间歇性的，日志看起来像网络抖动，排查方向很容易跑偏，有时能拖几周才定位到是任务时间撞车。
怎么避：坚持一仓一源。确实要汇聚的，要么错开执行时间并加执行前锁检查，要么用 borg serve --append-only 加 --restrict-to-path 把各客户端隔离到独立目录，同时配文件系统配额，防止单个客户端灌满整块盘。
翻车点四：为了省 CPU 关掉加密，或者开了加密却丢了密钥。
为什么坑：两个极端都常见。前者觉得内网安全，结果勒索软件横向移动进来，备份连同生产数据一起被加密；后者开了 repokey，passphrase 只存在运维自己的记事本里，人离职或机器重装后几十 TB 数据变成无法解密的乱码。
怎么避：加密默认开着，确认 CPU 支持 AES-NI 就行，那点吞吐损失不值得拿数据安全换。密钥这边强制做离线双份：passphrase 和 borg key export 导出的密钥分开存放，纸质件进保险柜，并写进运维交接清单。
翻车点五：borg check 半年没跑过，真要恢复才发现数据坏了。
为什么坑：备份成功的日志不等于数据可恢复。磁盘静默错误、segment 位翻转、传输过程中的损坏，都不会在 create 时报错，只有 --verify-data 能发现。等真出事要恢复时才发现校验失败，这时候已经没有第二次机会了。
怎么避：元数据校验跟着每次备份走，--verify-data 按季度排独立窗口，提前确认磁盘、内存、时间三项都不冲突。校验失败的仓库立即停止写入并保留现场，同时从第二副本验证数据可用性。
翻车点六：备份服务器和数据源放在同一台机器或同一个故障域。
为什么坑：最常见的"备份"是把数据备份到本机另一块盘上，或者同一机柜的另一台机器。硬盘控制器故障、机柜断电、机房级事故一来，两边一起没。这种备份在真正的灾难里恢复成功率为零，但因为有备份日志，心理上又很安全——这比没有备份更危险。
怎么避：物理分离是底线，跨机柜、跨机房更好。备份链路走 SSH 并限制为 append-only，让被攻陷的源端删不掉备份端的历史归档。有条件就做两地三副本：本地仓库 + 异地仓库 + 一份长期冷备。
Q1：Borg 备份服务器的内存到底要配多大？
别按仓库容量算，按 chunk 总数算。经验值是每个 chunk 约占 100 字节的索引开销，加上进程本身的运行时开销，实测通常比理论值高几倍。20TB 仓库、默认 2MB 平均块，chunk 数约 1000 万，索引理论 1GB，实际 create 占用常见 4–8GB，配 64GB 比较从容。若你把平均块压到 512KB，chunk 数翻 4 倍，内存预算同步翻 4 倍，128GB 起步。留一倍余量还有个理由：--verify-data 也要载入全量索引。
Q2：块大小该不该手动调？调小去重率能高多少？
大多数场景别调，默认 buzhash,19,23,21,4095（平均块 2MB 量级）是合理的平衡点。块调小确实能提高去重率，收益最明显的恰恰是 VM 镜像、数据库裸文件这类"大文件频繁局部改动"的数据，逻辑量 10TB 以下时值得一试。但对海量小文件几乎没收益，因为小文件本来就不够一个块。代价是 chunk 数成比例上涨，内存和 create 时长同步上涨，而且参数一旦定下就不能中途改。
Q3：lz4 和 zstd 选哪个？
默认选 zstd，档位 3 左右。理由是 zstd 压缩率明显好于 lz4，而且可以多线程压缩，核数能直接换算成备份窗口。lz4 的唯一优势是快，但这个"快"省下的 CPU 时间，远不如它多占的磁盘值钱——仓库越大 chunk 越多，内存压力也跟着来。只有一种情况我选 lz4：CPU 特别弱或者已经确认是 CPU 瓶颈。zlib 基本没必要选，none 只用在数据本身已压缩或已加密的场合。
Q4：开启加密后备份会慢多少？
加密是纯 CPU 活，默认 repokey-blake2 加 aes-ctr，开启后吞吐下降是肯定的。关键在于 CPU 有没有 AES-NI——现代服务器级 x86 基本都带，硬件指令把 AES 开销压得很低，实测损失通常能控制在一个可接受的范围。没有 AES-NI 的老平台或低功耗 CPU 上，掉三到五成吞吐都不稀奇。所以判断标准很简单：先确认 AES-NI，确认了就放心开着，别为了省 CPU 关加密。
Q5：prune 执行完磁盘一点没变小，是不是命令没跑对？
命令跑对了，只是 prune 本来就不释放空间。它只在元数据层面标记哪些归档该删、哪些 chunk 成了无引用，字节仍然躺在 segment 文件里，df 当然没变化。真正回收要跑 borg compact（较新版本），它会把仍被引用的 chunk 重写进新 segment 再删掉老的；旧版本只能用导出再重建的方式。注意 compact 期间新老 segment 并存，需要接近仓库大小的空闲盘，这一步没留余量就会中途失败。
Q6：borg check 多久跑一次合适？
分两层。不带参数的 check 只校验元数据，成本可接受，跟着每次备份跑没问题。带 --verify-data 的全量校验要读遍所有 segment 并重算哈希，CPU、磁盘 IO、内存三项同时打满，20TB 仓库在机械盘上光读盘就要 30 小时往上，必须单独排窗口。频率按 RPO 定：能接受一天数据丢失的，季度一次够了；核心库要求接近零 RPO 的，就把仓库拆小，让单次校验能在一两个晚上跑完。
Q7：多个业务部门能不能共用一个仓库？
不建议。Borg 用锁文件防并发写，多客户端同时 create 会撞锁报错，而且失败是间歇性的，日志看起来像网络抖动，很难定位。更主要的是去重的收益并不大——不同机器的系统文件和公共库重复度有限，合仓省不了多少空间，却换来锁冲突、权限混乱、一个客户端被攻破连累全部备份三个麻烦。标准做法是一仓一源，需要汇聚就用 append-only 加 restrict-to-path 做隔离。
Q8：租用备份服务器时，磁盘和内存哪个更该加钱？
先保证磁盘容量，因为磁盘不只是装仓库，还要留 compact 的临时空间——按仓库目标容量的 1.5–2 倍采购，compact 峰值需要接近仓库大小的空闲盘。内存按 chunk 总数算够就行，20TB 仓库配 64GB 通常够用，不需要一味堆到 256GB。顺序写为主的负载用大容量企业级机械盘组 RAID6 就很合适，随机 IOPS 要求不高，钱花在容量上比花在 NVMe 上划算。网络别忽略，1Gbps 理论约 110MB/s，跨地域备份时它是窗口的另一半。
如果这篇只记住一句话，那就是：Borg 备份服务器的内存由仓库内 chunk 总数决定，而 chunk 总数和块大小成反比；磁盘则要额外预留 compact 期间接近仓库大小的临时空间。前半句决定了你会不会在某天夜里 OOM 导致备份静默失败，后半句决定了你能不能在半年后顺利回收空间。
落到采购单上，我的取舍顺序很明确：磁盘容量第一，内存第二，CPU 核数第三。磁盘按目标仓库容量的 1.5–2 倍买，用大容量企业级机械盘组 RAID6，别在 NVMe 上浪费预算；内存按平均块大小和仓库容量反推 chunk 数再乘 100 字节、再乘一个几倍的实际系数；CPU 保证 16 核起步并确认带 AES-NI，核数越多 zstd 压缩段越短。100TB 这种规模，与其堆一台巨兽，不如拆成五个 20TB 仓库——单次索引内存、单次校验时长、故障爆炸半径，三项同时变好。
最后一条是老生常谈但必须说的：备份的唯一价值是能恢复。配置再漂亮，没跑过 --verify-data、没实际拉过一次恢复演练，那都只是心理安慰。把校验和恢复演练排进季度计划，比多买两条内存重要得多。
本文涉及的一万网络机型与服务信息，参考自一万网络官网相关页面（https://www.idc10000.net/）数据备份服务器租用与裸金属服务器栏目，品牌口径为深耕 IDC 19 年（成立于 2007 年）。文中配置档位为技术选型参考，所有价格均为预估价格，以咨询为准，具体以签约时最新报价与合同为准。
技术参数部分参考 BorgBackup 官方文档中关于 chunker-params、segment 大小、压缩算法与加密模式、prune 与 compact 行为、check 校验层级的公开说明；索引内存与 chunk 数关系为基于每 chunk 约 100 字节开销的量级推演，不同数据类型与 Borg 版本下会有出入，实际以本机实测为准。
上一篇：印度 DPDP 规则落地后先改哪三处：同意取证、90 天请求响应和泄露通报
下一篇：2026 Puppet 配置管理服务器租用 JRuby 并发与 PuppetDB 容量规划手册：catalog 编译/节点数 对比 + 避雷全解
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
