为 VPS 做异地加密备份

人们往往把难的部分做完，却把容易的部分晾在一边。服务器做过一遍加固，用密钥代替密码登录，防火墙默认拒绝，也许还上了全盘加密，关机之后磁盘上的内容毫无意义。然后每天晚上，这块磁盘上所有内容的一份完整明文副本，被推送到一个几年前用银行卡开的存储账户里，放在一个没人认真想过的国家，由一个同时也存在浏览器里的密码守着。

副本值得和原件同样的重视，因为它就是原件，只不过没在运行而已。值得把你究竟在防什么说具体一些，因为几种情况的答案各不相同，而人们脑子里想到的，通常只有其中一种：

• 机器挂了。硬件、hypervisor，或者一个重启后变成只读的文件系统。少见，平淡，也是所有备份都能应对的情况。
• 你自己把它搞坏了。一次跑了一半的迁移、一条通配符写得过于豪迈的 rm、一处直到重启前都好好的配置改动。这是人们做恢复最常见的原因，没有之一。
• 别人拿到了 root。这是决定你整个设计的那种情况。想要筹码的攻击者会先删备份，再加密服务器；如果你的服务器上存着一个能抹掉备份仓库的凭据，那你搭建的就是一套帮他们干活的系统。
• 账户没了。一笔没到账的付款、一场争议、一次封停。如果原件和副本都在同一个登录之后，它们就共享同一个单点故障，而且这个故障跟技术无关。
• 有权力的人找上门来。硬件可能被收走，账户可能被冻结，靠的是程序而不是攻击。这时唯一管用的，是一份放在另一个司法辖区的副本，而且前提是你还能访问到它。

留意一下：由你自己的服务商、在你自己的账户下、在同一个数据中心里拍的快照，对上面这些情况里的多少种根本无能为力。

这条原则来自摄影，而不是系统管理 — Peter Krogh 当初是为手里握着无法替代的底片的人写下它的 — 它能流传下来，是因为够短：数据保留三份，放在两种不同的系统上，其中一份在异地。每一位数字防的都是上面清单里不同的一项，这让它不只是一句口号。

三份应对的是普通的数据丢失：线上数据加两份备份，这样发现某份备份坏了，只是件烦心事，而不是世界末日。两种不同的系统应对的是关联故障 — 同一台主机、同一个阵列或同一个账户里的两份副本，不过是一份副本换了身伪装。而异地那份，应对的是一切发生在某个地点、而非某块磁盘上的事：火灾、查扣、封停，还有一个再也联系不上的服务商。

它的现代扩展版是 3-2-1-1-0，而在 2026 年真正要紧的，恰恰是多出来的这两位。多出来的那个 1，是一份不可篡改或离线的副本 — 一个拿着你凭据的攻击者也删不掉的东西，而这正是仅追加模式给你的。0 指的是校验零错误：一份你检查过的备份，而不只是一份你做过的备份。

放到一台小型 VPS 上，这条原则落地起来比听上去朴素得多。线上服务器是第一份。另一个国家第二台机器上的仓库是第二份：异地、不同系统，而且因为是仅追加，它同时也是那份不可篡改的副本。每月一次恢复到临时服务器上的完整恢复，就是那个 0。整条原则就这么满足了，代价只是多一台小服务器，而这份指南余下的部分，讲的就是具体怎么做。

这两个工具做的是同样的四件事，而且都做得很好：按内容给数据分块，所以移动或重命名过的文件不会被重新上传；跨所有快照去重，所以一年的每日备份，占用的空间远比一年的完整拷贝少；压缩；以及 — 这里最要紧的一点 — 在客户端完成加密和认证，赶在任何一个字节进入网络之前。两种情况下，存储端保存的都是它读不懂、也无法在不被察觉的前提下篡改的密文。正因为有这个特性，这份指南对“谁来运营你的存储”没有立场。

真正的差别，都在另一端。

• restic 是一个静态编译的 Go 单文件程序，对目标端没有任何要求。它能写入 SFTP、S3 兼容的对象存储、它自己的 REST 服务器，或者任何 rclone 能访问到的地方。加密用的是 AES-256 配合 Poly1305 认证器；仓库格式 2 加入了压缩。如果你的目标是一个存储桶，或者一台你没法装软件的机器，答案就是 restic，没什么好争的。
• Borg 要求两端都装上 borg，通过 SSH 和自己对话。作为交换，它提供了 restic 需要借助辅助程序才能做到的东西：一个真正由服务器强制执行的仅追加模式，通过远端账户 authorized_keys 里的 command= 选项锁定。客户端 — 包括已经被攻破的客户端 — 可以添加归档，却无法删除。对上一节的威胁模型而言，这是两个项目中最有价值的一项功能。

所以决定起来很简单。如果另一端归你控制，就用开启仅追加模式的 Borg。如果不归你控制，就用 restic，再通过在目标端运行 rest-server --append-only，或者使用开启了对象锁定的存储桶，把同样的保障找回来。两条路下面都会讲到。

在选定仓库之前还有一点要提醒：Borg 的命令接口在不同大版本之间并不稳定 — 下文用到的 repo::archive 简写属于 1.x 系列，到了 2.x 就变了 — 所以要拿 borg --version 去对照你正在读的文档，而不是反过来。restic 在这方面要稳定一些，代价是它自己也经历过一次仓库格式迁移。

有一件事不要做：以“两份备份总比一份安全”为由，两个都跑。两套维护得半吊子的系统，只会给你两个没验证过的仓库，外加一套在压力之下想不起来的恢复流程。选那个适合你另一端的工具，把省下的精力花在测试它上。

上面这些都是标准建议。下面才是通常被略过的部分。

备份服务器的常规做法，是给它一个凭据，让它往外推送。而这个凭据几乎总是也能删除 — 因为清理旧快照需要删除权限，而发一把什么都能干的密钥更省事。后果就是：拿下你服务器的攻击者，也一并拿下了你的备份，而在你最需要备份的那个场景里，它恰恰一文不值。出路只有三条：

• 在目标端启用仅追加。不管客户端提出什么请求，另一端都只接收新数据、拒绝删除。borg serve --append-only 和 rest-server --append-only 都能做到，并且由服务器端强制执行，删除则变成你在备份主机上有意为之的操作。
• 对象锁定。S3 兼容存储可以让对象在保留期内不可更改。有效，只不过它把信任转移到了一家服务商和一段付费关系上。
• 用拉取代替推送。由备份主机主动连进来读取数据。生产服务器上的任何东西都碰不到仓库 — 但现在备份主机手里握着一把进入生产环境的钥匙，所以你只是把信任关系反转了，而不是消除了它。如果备份主机确实被锁得更严，这样做是合理的；否则并不见得更好。

仅追加这条路最便宜，前提条件也最少，所以下面搭建的就是它。

然后是放在哪里的问题。备份是你服务器的一份完整副本，它受所在地的法律管辖，挂在某个人名下的账户里。精挑细选了服务器的司法辖区，然后每晚把副本推送到另一个完全不相干地方的存储桶里，这是一种常见而又不声不响的错误 — 副本在哪个司法辖区，数据就在哪个司法辖区。客户端加密能在很大程度上缓解这一点：向你的存储服务商发出的调取要求，拿到的只是密文。它保护不了的是可用性，也掩盖不了仓库存在这一事实、它有多大，以及它最后一次变动是在什么时候。

正因如此，一次解决最多问题的方案，是第二台同样归你所有的小服务器，放在和第一台不同的国家，用和第一台相同的方式租下：不绑定任何身份，免实名，用 Monero 支付。两端都是你的，两端都便宜，传输从不经过第三方，而且无论原服务器所在的司法辖区或账户出了什么事，都波及不到这份副本。

给它选配置，比给一台真正干活的服务器选配置容易，因为备份目标说白了就是一块带着 CPU 的磁盘。它真正需要的，是足够的内存，好让清理（prune）和完整性检查跑起来不至于疯狂换页，这是唯一真正吃资源的环节 — 所以 1 GB 偏紧，2 GB 就宽裕了。对照套餐列表：

• Cub — 1 vCPU / 2 GB / 40 GB NVMe，$5.00/月。默认之选。一台普通的 Web 或应用服务器，线上数据 10–15 GB，保留一年的每日备份，放在这里绰绰有余，因为大部分工作都由去重和压缩完成了。
• Scout — 2 vCPU / 4 GB / 70 GB，$9.00/月。适合把几台服务器备份到同一个仓库，或者一套存着照片的 Nextcloud。
• Runner 和 Hunter — 100 GB 售 $14.00，140 GB 售 $19.00。邮件存储、媒体库或好几年的历史记录，最后都会落到这一档。
• Pup — 1 vCPU / 1 GB / 25 GB，$3.50/月。只备份配置和数据库转储的话够用。别把一棵庞大的文件树丢给它，还指望维护操作能一直顺顺当当。

磁盘容量有一条好用的经验法则：按单次完整备份大小的两到三倍来规划，你就能留住一年的历史，还有余地容你估错。把它放在一个不是原服务器所在地的地方 — 阿姆斯特丹、巴黎、布加勒斯特和索非亚都是基础价，雷克雅未克乘以 1.20，苏黎世乘以 1.35，也就是说一台放在瑞士的 Cub 每月 $6.75。首次上传是你唯一一次大流量传输，而且 1 Gbps 端口流量不限，所以初次填充仓库不会在月底给你带来一张账单。

保留策略，是人们悄无声息地弄丢本来还在的数据的地方。保留七个每日快照，感觉挺负责，实际上只能防住你一周之内就发现的问题。静默损坏、被某个 bug 写成截断状态的数据库、四月删掉而六月才需要的文件、一个在做出任何可见动作之前先潜伏了很久的入侵者 — 这些都是在那七天早已轮换完之后很久才被发现的，到那时，每一个快照都忠实地保存着损坏后的状态。

标准做法是分层保留，而这几乎不花什么成本，因为有了去重，变化缓慢的数据做一个月度快照，占用的空间小到可以忽略不计：

restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --keep-yearly 2 --prune

borg prune --keep-daily=7 --keep-weekly=5 --keep-monthly=12 --keep-yearly=2 ::
borg compact

有两个机制上的细节值得了解，因为它们都让人吃过一惊。在 restic 里，forget 只是把快照从索引中移除，并不回收任何空间；真正删除数据的是 prune 这一步，所以命令里才带着这个参数。在 Borg 里，prune 会删除归档，但仓库并不会变小，直到 borg compact 运行为止 — 它被做成一条单独的命令，正是为了能单独安排运行时间。

这和上一节确实存在矛盾：清理需要删除权限，而你刚刚把删除权限从客户端手里收走了。这是正确的取舍，而不是设计缺陷。解决办法是在备份主机上做清理，在那里仓库是本地的，客户端没有发言权 — 在目标端设一个每周运行的定时器，全程不需要生产服务器参与。如果你嫌这套机制太重，替代方案是准备第二把不带 --append-only 的 SSH 密钥，不放在生产服务器上，每隔几个月手动用一次。你不该做的，是为了让一个 cron 任务简单点，又把不受限制的密钥放回服务器上。

一个停止运行的备份任务，和一个无事可做的备份任务，输出完全一样：什么都没有。这是备份在运维上的决定性特征，也是大多数坏掉的备份会一直坏上好几个月的原因。有三样东西值得接上，按价值从低到高排列：

• 失败告警。systemd 单元可以通过 OnFailure= 在失败时触发另一个单元，由那个单元给你发一条消息。必要，但却是三者中最弱的，因为它只有在某个东西真的运行了、并且报了错时才会触发。
• 时效告警。询问仓库最后一次收到数据是什么时候，如果答案超过一两天，就发出告警。这能抓住被屏蔽（mask）的定时器、写满的磁盘、解析不了的主机名 — 所有那些因为根本没跑、所以从来不会报错的故障。
• 死人开关。把逻辑反过来：任务成功时去 ping 一个 URL，一旦 ping 停了，就由外部的某个服务向你告警。这是唯一一种在整台服务器都没了的情况下依然有效的办法，而这种故障，你最不希望是从客户那里得知的。

最划算的是时效检查，只要三行：

#!/bin/sh
# alert if the newest snapshot is older than 36 hours
last=$(restic snapshots --json --latest 1 | grep -o '"time":"[^"]*"' | head -1 | cut -d'"' -f4)
[ $(( $(date +%s) - $(date -d "$last" +%s) )) -lt 129600 ] || echo "BACKUP STALE: $last"

目标端的磁盘也要盯着。备份卷一旦写满，此后的每个任务都会失败，而且是在最后才失败 — 在传输完成之后，这是发现问题代价最高的方式。在用量达到百分之八十时告警，能给你留出几周的提前量；不设告警，就一点提前量都没有。

大致按它们把备份变成纪念品的频率排序：

• 数据库在运行时被直接拷贝。在写入中途被抓取的 InnoDB 数据目录，恢复出来是一个启动不了的数据库，而且这一切悄无声息 — 备份顺利完成，文件一个不少，大小看起来也对。先转储。它被排在第三步，是有原因的。
• 口令只存在服务器上。一个完美无瑕的加密仓库，如果它的口令放在那台已经烧毁的机器的 /root 里，那它就只是一堆高质量的噪声。口令存在密码管理器里、而这个密码管理器唯一的副本又是通过同一台服务器同步的，也是一样。
• 从来没人做过恢复。排除列表过于激进，数据库转储连续三个月都是空的，路径写错了。这些问题在恢复之前全都看不见，而一旦做了恢复，十分钟之内就一目了然。
• 备份放在同一个账户里。同一家服务商、同一个登录、同一段付费关系。应对磁盘故障没问题，除此之外一概无用。
• 客户端能执行删除。勒索软件会在碰数据之前先删掉备份，因为它的整个商业模式就建立在这上面。要么启用仅追加，要么接受这种情况你防不住。
• 目标端悄悄被写满了。保留策略从来没执行过清理，或者包含列表里新加了一个大目录。此后的每个任务都会失败，而如果你没做时效监控，没有任何东西会告诉你。
• 区块链数据进了备份。备份 Bitcoin 或 Monero 的数据目录，等于花钱存储一本你随时可以免费重新下载的公共账本。备份钱包和配置文件；把链数据排除掉。
• 排除列表误吞了东西。一条本来针对 /var/cache 的规则，同时匹配到了某个应用的缓存目录，而那里面存着应用永远不会自己重建的状态。把第一次备份的文件列表认认真真读一遍。
• 恢复需要的密钥就存在仓库里。Borg 的 repokey 模式把密钥保存在仓库内部，这很方便，直到你丢的恰好就是仓库本身。一开始就用 borg key export 把它导出到别处，做一次就够。

老老实实说清四个局限，因为一份把备份吹过头的指南，和一份没测试过的备份，干的是同一件事。

备份不是高可用。它能缩短停机时间，却不能避免停机。恢复一台服务器，意味着开通机器、拉取数据、解包、重新配置 — 规模小的也得足足一个小时，要是你上一次尝试恢复是“从来没有”，花的时间还要多得多。如果一个小时的停机你无法接受，答案是一台备用机，而备份依然必不可少，因为备用机会忠实地复制一切，包括你犯的错。

加密并不会让副本隐形。它让副本无法被读取，这是两回事。托管仓库的一方依然能看到它的存在、它有多大、它最后一次变动是什么时候 — 而为它付费的那个账户，和其他任何信息一样，都是能识别身份的细节。如果当初让你以免实名方式租下原服务器的理由依然成立，那它对第二台机器同样成立；同一套结账流程两台都适用。

静态加密并不等于在任何意义上都是端到端加密。restic 和 Borg 保护的是仓库。它们保护不了正在运行的服务器，那里的数据按定义就是明文；如果口令连同保存它的机器一起失守，它们也无能为力。源服务器上的全盘加密，和一份在两台机器之外另行保管的口令，是互补的控制措施，而不是重复的。

还有，放在另一个国家的副本，带来的是阻力，而不是豁免。司法辖区改变的是谁需要向谁提出请求，以及要花多长时间 — 离岸主机托管词条对这一点有详细论述。这里的两台机器都遵守同一份明文写出的可接受使用政策，底线也完全相同。这种安排真正换来的，是任何单一故障 — 一块坏掉的磁盘、一条敲错的命令、一个入侵者、一个被冻结的账户 — 都不会同时带走原件和副本。这正是备份存在的意义，而这就够了。