Restic vs BorgBackup：对象存储与 SSH 加密备份怎么选？

详细比较

先看备份要放在哪里

需要把不同系统的数据备份到对象存储，通常先评估 Restic；已经有自己管理的备份服务器，希望通过 SSH 集中保存 Linux 文件，则可以先评估 BorgBackup。两者都围绕可恢复的历史版本工作，不能只用同步目录代替它们的备份语义。选择前应写下源机器、目标存储、负责人和恢复时限：是否必须支持 Windows，是否只拥有对象存储账号，是否有人维护远端服务器。这些条件会直接改变配置和交接成本，比抽象比较哪一个更专业更有用。

依据：官方资料；选择条件为编辑分析。

本文只比较当前稳定版本

截至二〇二六年十月十一日，Restic 官方最新稳定发布为 0.19.1，七月五日发布；Borg 官网列出的当前稳定系列为 1.4，当前版本 1.4.5，七月十九日发布。Borg 2 九月底仍有测试发布，官网明确提示测试阶段不用于生产。本文按稳定版能力讨论，不把开发分支的存储后端、平台支持和命令直接算入 Borg 1.4。选择时应查看所安装版本的文档，而不是让搜索结果中的最新命令替换已经验证的生产流程。

依据：官方资料、官方资料、官方资料；选择条件为编辑分析。

对象存储与远端程序的分界

Restic 官方文档提供本地、SFTP、REST、S3 及其他存储后端的配置路径；适合按现有存储服务选择仓库。使用 SFTP 时，远端不需要运行 Restic 程序，但仍需正确设置访问和权限。Borg 1.4 的典型远程方式通过 SSH 调用远端 Borg，双方环境与版本都需要维护。它也能使用本地目录，不能简单说只能联网备份。关键分界是你拥有普通存储接口，还是能够管理远端备份程序。只有对象存储账号的人，通常会在 Restic 上获得更直接的部署路径。

依据：官方资料；选择条件为编辑分析。

跨平台与文件语义要一起比较

Restic 的官方安装资料包括 Windows、macOS 和 Linux 等平台；Borg 1.4 的官方支持重点为类 Unix 环境，Windows 路径需要单独评估兼容方案，不能把 Borg 2 的 Windows 测试构建算作稳定版支持。跨平台不仅意味着命令可以启动，还涉及权限、链接、文件名与恢复后的可用性。若团队主要备份 Windows 工作目录，先试 Restic 更合理；若主要保护 Linux 文件树且已有 Borg 运维经验，保留现有工具可能更省交接。代表性文件恢复应作为采用条件。

依据：官方资料、官方资料；选择条件为编辑分析。

去重不等于任何数据都节省空间

两者都提供去重与压缩相关能力，适合保存多次历史备份；实际节省程度取决于文件内容、变化方式和配置。大量相似文本与已经压缩或加密的媒体并不会得到相同效果。对每天重新生成的数据库导出文件，还应使用真实数据样本观察增量与恢复代价。本文没有做统一数据集测试，因此不提供节省比例或速度排名。选择应结合当前仓库增长、可用容量和备份窗口，不能把某个厂商或社区展示的漂亮比例直接套到自己的业务上。

依据：官方资料；选择条件为编辑分析。

运行中的数据库需要一致性来源

文件备份工具可以保存文件，却不能仅凭一次复制就保证正在写入的数据库处于可恢复状态。编辑建议是先明确数据库导出、应用暂停写入或合适的快照流程，再让 Restic 或 Borg 保存稳定的结果。还要决定上传目录、配置、导出数据和外部对象是否在同一次恢复范围内。网站能打开不代表备份已经完整，备份命令成功也不代表恢复后的应用能连接数据。选型时把一致性准备所需的权限与时间算进去，避免只测文件传输部分就宣布业务备份已经解决。

依据：官方资料；选择条件为编辑分析。

加密需要配套的恢复资料

Restic 仓库依赖密码访问，官方提醒丢失密码会使数据无法恢复。Borg 的密钥模式、密钥位置与口令也需要在初始化时确认，并按官方方式导出恢复所需的密钥资料。加密可以保护存储内容，但无法替代凭据保管和人员交接。应把恢复材料与仓库放在不同故障范围内，并在隔离环境验证拿到材料后能够解锁备份。不要把云账号、仓库密钥和唯一恢复说明都只留在被备份的电脑上，也不要把配置中出现加密字样当作恢复方案已经完整。

依据：官方资料；选择条件为编辑分析。

加密与防删除属于不同问题

客户端能够写入备份，通常也可能拥有某些删除能力；仓库加密不会自动阻止客户端被入侵后的破坏。Borg serve 提供追加模式和路径限制等能力，适合将常规备份与管理删除权限分开。Restic 的权限边界取决于采用的后端，不能把所有对象存储、SFTP 和 REST 服务都视为具有同一保护方式。若有防勒索需求，应单独验证被攻陷的客户端能否删除历史、管理凭据由谁持有以及清理流程怎样运行。这里比较的是实际权限架构，不是给软件名称打安全分数。

依据：官方资料；选择条件为编辑分析。

保留策略与释放空间需要区分

Restic 的 forget 用于删除快照引用，prune 处理不再需要的数据；Borg 1.4 的 prune 按规则保留归档，compact 才承担相应的空间整理。保留最近若干天、每周和每月版本之前，要检查规则是否覆盖真正需要的恢复时间点。编辑建议先使用预演输出审查候选范围，再执行授权的清理，不要为了腾出空间临时拼接删除命令。选择时关注维护者能否理解保留、清理与中断恢复的边界；一套看不懂的自动化规则，比多保留几个版本更容易带来实际风险。

依据：官方资料、官方资料、官方资料；选择条件为编辑分析。

对象存储的账单不只有容量

Restic 可以直接接入多种存储后端，但服务商可能对容量、请求、下载和取回分别收费；具体费用要以所选服务的当前计费规则为准。Borg 的 SSH 服务器通常需要磁盘、主机、网络和管理成本，使用第三方 Borg 托管也可能有订阅费用。两者的软件与存储服务应分开核算，不能用没有软件订阅费推出总体成本为零。建议按完整备份、日常增量、周期清理和一次大规模恢复计算工作量。只比较平时上传的数据量，容易遗漏真正恢复时的网络与时间成本。

依据：官方资料；选择条件为编辑分析。

恢复体验必须按真实故障验证

Restic 提供恢复到指定目录的路径，Borg 也能提取归档；支持挂载浏览并不意味着每个平台都具备相同的挂载依赖。演练应先挑一个旧版本文件，再恢复一组带权限与链接的目录，最后验证应用是否能读到正确数据。灾难恢复还需要机器环境、账号权限、软件版本和密钥，不只是文件列表。若主要需求是跨机器快速拿回工作文件，评估新环境安装与取回步骤；若是 Linux 服务恢复，评估权限和业务启动。熟悉的恢复流程可以成为保留现有工具的充分理由。

依据：官方资料；选择条件为编辑分析。

仓库检查与业务演练不能互替

Restic check 与 Borg check 可以检查各自仓库的一致性，完整的数据读取验证又可能涉及额外选项和较大的工作量。检查没有报告错误，能够提供仓库层面的证据，却不能单独证明数据库导出正确、业务配置齐全或恢复时间足够短。建议分开安排日常备份结果检查、周期仓库检查和真实恢复演练，并确认失败有通知负责人。选择时考察网络下载、CPU、磁盘和时间窗口是否允许这些工作，避免把检查命令写进计划后就长期忽略它的实际执行状态。

依据：官方资料、官方资料；选择条件为编辑分析。

已有历史仓库怎样考虑迁移

Restic 与 Borg 的仓库格式不能直接互换，改用另一工具意味着重新建立可恢复的历史和维护流程。编辑建议保留旧仓库及对应恢复材料，在新工具上独立完成代表性备份与恢复，再决定旧历史怎样归档。不要把迁移简化成把旧目录改一个名称，也不要在新方案尚未验证时先删除旧备份。若现有 Borg 与 SSH 流程已经稳定，只有新增对象存储或跨平台需求才可能带来足够迁移动机；若现有 Restic 能覆盖需求，也不必为了另一种压缩选项承担整套历史迁移。

依据：官方资料；选择条件为编辑分析。