备份仓库删掉一批旧快照，服务器磁盘占用却几乎没变，此时直接给Linkcli候选主机加盘，很容易买错资源。采购要先分开两件事：哪些历史版本还允许恢复，哪些底层数据已经可以物理回收。前者由保留策略决定，后者还要经过清理、重打包和写入暂存；如果只用快照数量估算磁盘，账面余量可能在维护窗口里突然消失。
一份保留清单，不能直接换算成已释放的容量
restic官方文档明确把移除快照与回收数据分为两步：forget移除快照引用，prune再删除只被已移除快照引用的数据。仍有其他快照需要的块会继续保留，因此删掉一个体积很大的目录版本，不代表仓库会等量缩小。这里的判断针对restic仓库机制，不代表Linkcli提供托管备份、自动清理或任何特定存储功能。
假设两份快照都引用同一份基础文件，只是在后来的快照增加少量内容。删除较早快照后，共享部分仍被后一份引用；真正可能回收的是不再被任何保留快照引用的独有数据。反过来，每天覆盖一份已经加密或压缩的大归档，逻辑文件名虽然没变，底层可复用程度却未必像小文件集合那样理想。不能用“每天只改了一点业务数据”替代仓库实际新增量。
采购需要的是保留策略执行后的仓库峰值，而非快照列表里文件大小的简单相加。先记录一个完整业务周期内每次备份的新增存储、维护前后的占用与任务耗时，再决定加盘是否能解决问题。若清理根本没有执行，新增硬盘只是把同一个维护缺口延后暴露；若所有保留版本确实引用了大部分数据，删更多目录也未必产生预期收益。
重打包还会改变维护期间的读写路径。官方说明，部分使用的数据包在重打包时需要从仓库下载，再上传仍然需要的数据；远程仓库可能因此产生明显时间与传输成本。本机保存仓库和通过网络维护仓库，应分别记录磁盘写入与网络方向，不能把它们都叫成“清一次垃圾”。
先画出两个时间窗，再决定是否需要更大磁盘
容量预算可写成一个采购用的上限模型：需要的可用空间＝当前有效仓库＋下次维护前新增量＋重打包暂存＋故障余量。这不是restic官方容量公式，而是本文用于询价的规划模型；每一项必须用实际路径的记录替换，操作系统和其他业务占用另计。尤其要区分仓库端空闲空间、执行维护机器的缓存空间与恢复目标空间，它们可能位于三台不同的机器。
给出一组明确假设：当前有效仓库为300GiB，未来七天每天新增8GiB未被后续清理回收的数据，维护暂存预留40GiB，故障余量留60GiB。工具计算得到需求为456GiB。若候选磁盘扣除系统和现有业务后只有420GiB可用，模型就差36GiB；不能因为标称容量看起来接近便接受订单。这些数字是演算，不是Linkcli套餐、压缩率、实测或可用量承诺。
第一条时间窗是下次成功备份前的维护窗口。restic文档提醒，prune会锁定仓库，期间备份不能完成，维护要避开正常备份运行。如果夜间给维护两小时，实际却需要三小时，即使磁盘足够，新的恢复点也可能迟到。验收记录应包含维护开始、仓库可再次写入、下一份快照完成的时间，而不是只记录清理进程退出码。
第二条时间窗是故障后恢复业务的窗口。容量采购解决“存得下”，无法自动解决“来得及”。假设要从异地读回300GiB，在持续有效吞吐80Mbps、忽略协议及磁盘开销的理想前提下，仅传输下限约8.95小时。如果业务要求四小时内恢复，这条路径即使不计解密、落盘与应用检查也不达标。应改为提前准备副本、缩小优先恢复集合，或核实可达到的恢复路径，再讨论扩盘价差。
清理频率能换容量，也会占用维护资源
缩短清理间隔可能降低积压，但不保证总成本更低。若每次都触发大量小范围重打包，CPU、随机读写和远程传输可能变得更频繁；把允许的未使用数据压得很低，也需要与运行时间一起评估。restic提供允许部分未使用空间保留的清理选项，目的是在空间与重打包之间作取舍。采购时应比较在既定保留要求下能否按时完成维护，而不是要求仓库长期接近零冗余。
保留七份日备份，未必等于覆盖最近七个自然日
官方文档对按小时、日、周保留有一个容易忽略的限定：只计算实际存在快照的时间段。按日保留七份，在任务有中断时可能跨越更长日历区间；不同保留规则的版本还可能重合，不能把每日、每周、每月数量机械相加。如果采购需求写的是“最近七天可恢复”，验收要拿真实日期与任务缺口对照，而不是只检查留下七个ID。
另一个边界是分组。restic按策略处理快照时，默认按主机名和路径分组，再对每组分别应用保留规则。同一业务迁移后主机名变了，或脚本改了备份路径集合，可能出现多组各自保留的版本；采购方看到仓库增长，不能先推断去重失效。先列出组、日期、业务归属和最后可用恢复点，再用dry-run查看拟删除对象，确认没有把仍需保留的旧主机版本误当成废物。
对于这类需求，适合把Linkcli放入候选的前提，是商家愿意在订单中明确可用容量、远程备份访问方式、维护允许的负载与流量口径；本文未取得这些条款的当前核验结果。仅有海外服务器或防护宣传，不能证明其磁盘适合长时间重打包，更不能证明备份客户端拥有的权限能抵御整机失陷。需要不可删除副本或业务恢复服务的团队，应另行采购并验收对应能力。
把“检查通过”写成有范围的结果
普通restic check主要检查仓库结构与一致性，默认不会读完所有数据包来验证其内容；使用read-data才会读取全部数据，官方也提醒这会增加时间和带宽成本。所以“昨晚检查成功”必须附带具体模式，否则它无法回答老版本中某个文件是否真的读得回。目录可列出、数据可读取、业务可启动，是采购验收中不同的证据。
抽样读取可以把单次维护成本分散，但应说明覆盖方式。restic支持把仓库分成若干组逐组检查，也支持随机比例或随机大小抽样；官方明确，反复随机抽样并不保证最终覆盖所有数据包。 若团队需要周期性完整覆盖，就应保存分组计划与完成记录，并处理周期内新增的数据；不能把每天随机检查百分之十，说成十天一定验完。
最后仍要从保留快照恢复一组有业务意义的数据，在独立目标中核对内容与权限，并由应用确认可用。结构检查不能替代应用一致性，读回几个小文件也不能代表数百GiB恢复能在限定窗口内完成。对预算紧的小规模站点，可以先演练关键配置与近期内容恢复；对需要整库恢复的系统，应把数据库一致备份与恢复顺序写进方案，不能把任意运行中文件集合当成可启动的数据库备份。
Linkcli询价应交付一张维护条件单
渠道通推广资料采集快照将Linkcli列为海外服务器服务商。本轮渠道通接口超时，官网请求返回403，故这里沿用2026年10月30日保存记录中的推广入口，未核实现价、库存、线路、退款条件或套餐资源，也未验证本轮跳转可用性。下方链接有推广关系，供读者进入后核对订单，不构成可用性或优惠承诺。查看Linkcli服务器推广入口与当前订单条件。
询价单应明确询问：磁盘标称单位和扣除系统后的可用量是多少，重打包的持续读写是否受公平使用条款约束，异地读取如何计费，超量后是限速还是停用；同时要求说明维护时能否使用独立执行机、是否另收快照费用，以及退款是否对使用量或服务类型设限制。没有书面答案的项目列为未确认，不用销售页形容词补齐。
交付验收时留下保留策略的dry-run清单、一次prune的前后容量与耗时、带明确范围的check记录，以及一次独立恢复结果。若456GiB的演算模型在实际数据中成立、候选可用量仍不足，就选择更大磁盘或调整合规保留需求；若瓶颈是维护窗口或恢复路径，则优先更换执行安排与存储位置。订单比较以这份记录为准，省下来的月费才不会被一次无法完成的维护抵消。
用户评论