VPS 备份与恢复：加密、异地存放，且经过真正的测试

快照不是备份——而你两者都需要

快照是某个卷在某个时间点的副本，存放在与被复制的卷相同的底层存储上。这并不是批评，只是一种描述，它恰好说明了快照真正擅长什么，又做不到什么。这里的每一档套餐都包含每小时一次、保留七天的快照，恢复一次大约三十秒，它们正是服务器运维中最常见事故的正确答案：你在下午四点改了一个配置文件，服务从那以后就没再启动过。面对这种故障模式，没有任何其他手段能与之相比——它比任何备份工具都快，它已经在运行，而且不额外收费。

快照做不到的一件事，是在它所依存的那个东西消失之后继续存在。它与卷、主机、hypervisor，以及在大多数设计里的账户，共享同一个命运。如果机器被查封，如果账户被关闭，如果数据中心遭遇了极其糟糕的一天，快照也会随之一同消失——它是数据的一份副本，而不是一份独立的副本。在一个刻意做到无法确认你身份的服务商那里，这种区别绝非纸上谈兵：没有任何支持渠道能凭别人的记录帮你重建服务器，没有绑定手机号的找回流程，也没有挂着你真实姓名的账单记录。你留下了什么，你就只有什么。

七天的窗口期，对另外两种缓慢发生的故障也无能为力。你五周前删除的那个文件，早在你注意到之前，就已经从每一份快照里消失了。静默数据损坏——出问题的应用悄悄写入了细微错误的数据、一次糟糕的迁移、一个同步客户端忠实地把一个错误传播了出去——往往要到一个月后才被发现，而那时，每一份保留下来的副本都已经包含了这份损坏。真正能覆盖这两种情况的，是保留期更长、拥有真实历史记录的备份，而它们之所以能覆盖，恰恰是因为它们不是当前状态的连续镜像。

这里值得内化于心的框架由来已久，至今依然正确。3-2-1 规则要求保留三份数据副本，存放在两种不同类型的存储介质上，其中一份放在异地。现代版本又加了两位数字——3-2-1-1-0——多出来的那个“1”，是一份不可变或离线的副本，那个“0”，则是你上一次校验中发现的错误数量。这几个数字与其说是标准，不如说是一句助记口诀，但它们确实封装了真正重要的三个属性：独立性、不可变性，以及“这东西确实有效”的证据。每小时一次的快照，只能给你这三者之中的一个。

把这张表读作“两者都做，而不是二选一”的论据。快照负责频率与速度；备份负责独立性与历史记录。它们的成本不同，失效的方式也互不相同，而两者结合起来，远比把任何一个做双倍要来得可靠。

决定其余一切的两个数字

恢复点目标（RPO）指的是你能承受损失多少数据，以时间衡量——如果最后一份可用副本已经是六小时前的，你的 RPO 就是六小时，中间那六小时的工作成果也就没了。恢复时间目标（RTO）指的是在重建期间，你能承受多长时间不可用。后续的一切——计划、方法、第二份副本放在哪里、要花多少钱——都是从这两个数字推导出来的，而在确定它们之前就先选好软件，正是人们最终为一个没人问过的问题，找到一个精心设计的答案的原因。

随口一问，大多数人都会说零和零。那不是一个预算，而是一个愿望，而且它背后附带的代价，值得直说清楚：接近零的 RPO，意味着要做持续复制，而不是定时复制；接近零的 RTO，意味着要有一台已经热备运行的第二机器。这两者都能实现，但也都会让你所保护的那个东西的运营成本大致翻倍。对于绝大多数自建负载而言，诚实的答案是：恢复点大约在一小时到一天之间，恢复时间大约是几个小时——这个水平，一份定时的加密备份，加上一份有文档记录的重建流程，就能从容应付。

这两个数字，在同一台机器上，也会因数据集不同而不同，而正是这个细节让它们真正有用。邮件是最典型的例子：一封二十分钟前送达的邮件，不存在于任何其他地方，无法重新生成，而且发件人根本不知道它需要重发——所以邮件服务器需要一个以分钟为单位的恢复点，即便软件本身一个下午就能重装完毕。Bitcoin 节点则完全相反：链上数据有几百 GB，网络上的每一个节点都乐于再发给你一份，所以备份它基本上是在浪费磁盘空间；而它旁边的钱包文件却是无法恢复的，值得像保护私钥一样去保护它——因为它本来就是私钥。

最后一行的内容值得明说出来，因为一份讲备份的指南，显然有动机对此避而不谈。有些机器根本不需要备份。一台全部状态都来自 git 仓库的构建代理、一个用完即弃的沙箱、一个配置都保存在版本控制里的无状态反向代理——对这些机器来说，套餐自带的每小时快照就是完整且站得住脚的答案，正确的备份工程投入量就是零。搞清楚你的哪些服务器属于这一类，比把它们全都做一遍蹩脚的备份，更有价值。

该复制什么——以及一大堆你应该跳过的东西

本能反应是给整块磁盘做镜像，而在一台租来的虚拟机上，这种本能是错的。操作系统是可以丢弃的：在这里，一个全新实例的部署时间中位数是 41 秒，从发行版镜像源重装软件包，比从你自己的备份里恢复它们更快也更可靠。真正不可丢弃的，是一个小得出人意料的集合，而把这个集合明确地列出来，正是这项工作的大部分——一份能用一段话描述清楚的备份，是一份你能够验证的备份，而一份全盘镜像，只是一样你抱着希望去赌的东西。

这个不可替代的集合通常包括四类东西。第一，应用数据：maildir、数据目录、媒体存储、上传文件夹。第二，数据库，它需要单独处理，会在下一节讲。第三，密钥与凭证——这是人们会忘记、直到付出代价才想起来的一类。TLS 私钥和 ACME 账户密钥；如果你不想在每个客户端上重新信任一次指纹，还有 SSH 主机密钥；DKIM 签名密钥，没有它你的邮件就会开始认证失败；WireGuard 私钥；以及最重要的onion 服务私钥，它就是 .onion 地址本身：丢了它，这个地址就永久消失，没有任何注册机构可以申诉。第四，/etc 下你确实改动过的那一小部分文件，再加上让这台机器保持现有行为方式的 systemd 单元、cron 条目和防火墙规则集。

该跳过的那一堆东西要大得多，而且一旦说破，大多显而易见。像 /proc、/sys 和 /dev 这样的伪文件系统，是内核的视图，而不是数据。软件包缓存、容器镜像、虚拟环境和依赖目录，全都能在几秒钟内从一份锁定文件重新推导出来。超出你保留策略的日志，是那种去重效果很差、还会拖慢之后每一次运行的噪声。而像区块链状态、一个公共镜像源、一个可以重新抓取的媒体库这类可以重新同步的大体量数据集，值得你做一个明确的决定，而不是任由默认设置决定：备份 300 GB 的链上数据，每个月都要花真金白银，为的却只是避免一次原本可以免费进行、且在此期间服务只是降级而非中断的重新同步。

几乎每个人都投入不足的一环，是回答“恢复到什么里面去？”这个问题。没有目标的数据，算不上一次恢复。如果你的服务器当初是怎么搭建起来的，只存在于你的记忆里，以及一份你后来又弄丢了的 shell 历史记录里，那么无论仓库本身有多好，你的恢复时间都是没有上限的。解决办法既便宜又乏味：把部署步骤写成一个脚本，或者一份纯文本的操作手册，把它放在备份仓库内部，这样它就会随着数据一起被恢复出来，并且每次改动机器时都更新它。哪怕只是 100 来行笔记——软件包、版本号、配置文件位置、DNS 记录、各个服务必须按什么顺序启动——也能把糟糕的一周，变成糟糕的一个下午。

对于正在使用全盘加密的人来说，有一个细节值得特别指出：LUKS 头（header）和它的密钥槽，同样也属于你那个不可替代的集合。一个损坏的头，会把一块完好无损的磁盘变成一堆随机噪声；这个头只有几 MB 大小，备份它几乎不花任何成本。要像保管密码短语一样谨慎地保管它——同时拿到这两样东西的人，就等于拿到了整块磁盘。

数据库：你复制的那个文件，并不是数据库本身

这是一份原本堪称合格的备份，最终变得毫无价值的最常见方式。数据库引擎会把状态保存在内存里、保存在一份预写日志或重做日志里，还保存在正被持续修改的数据文件里。在引擎运行期间复制这些文件，会把它们捕捉在不同的时间点上——某张表的第四页取自一次事务之前，第五页却取自之后——结果得到的是一组单独看都完好、合在一起却互不一致的文件。残酷之处在于，这样一份副本通常还是能恢复的。它能启动，能响应查询，而损坏要到几周之后，才会以一个损坏的索引，或者一行违反了某条引擎信誓旦旦声称自己在强制执行的约束的记录，浮出水面。一份大张旗鼓失败的备份，远比一份悄无声息失败的备份要好得多。

正确的方法取决于具体引擎，而且每一种都有完善的文档。对 MariaDB 和 MySQL 来说，在单个一致性事务内完成的逻辑导出，适用于几十 GB 以内的任何规模；超过这个规模，就该用 Mariabackup，它能在服务器运行期间完成物理热备份。对 PostgreSQL 来说，pg_dump 能给你一份可移植的逻辑快照，而 pg_basebackup 配合归档的预写日志，则能给你时间点恢复能力——也就是恢复到 14:32 这个精确时刻，而不是恢复到上一次导出恰好运行的那个时刻。对 SQLite 来说，使用内置的在线备份功能，或者 VACUUM INTO；对一个正在使用中的数据库文件执行 cp，正是上文所说的那个错误，而 SQLite 恰恰是人们最常犯这个错误的引擎，因为它看起来就像一个普通文件。

数据库与它所描述的文件之间的一致性，是这个问题的后半部分，也是专门会咬文件同步和论坛类软件一口的那部分。数据库说某个路径上存在一个文件；而文件系统才是字节真正存放的地方；如果你在 02:00 导出数据库，又在 02:40 复制数据目录，那么在这之间创建的所有东西，要么是有字节却没有对应记录的数据，要么是有记录却没有对应字节的数据。提供维护模式的应用——Nextcloud 就是最明显的一个——通过在两者被同时捕捉的短暂时间里拒绝写入，来解决这个问题。在无法接受这种做法的场合，一次性完成的文件系统或卷快照，能给你一组一致的数据，供你从容复制，这正是每小时快照所使用的同一个技巧。

有一个微小的运维细节，立刻就能让自己回本：导出时保持不压缩，把压缩的事交给备份工具去做。restic 和 borg 都是按内容定义的分块方式来去重的，所以相隔一天的两份导出，绝大多数数据块都是共享的，第二份导出的存储成本几乎为零。要是先把导出结果压缩了，那么靠近开头的一个字节发生变化，就会连锁影响整条压缩后的数据流，导致没有任何数据块能对上号，每一次运行都会存下一份完整副本。团队们经常会发现，自己的仓库正因为这个原因，每天都在以整个数据库大小的速度增长——而修复方法，只是从 shell 脚本里删掉一个管道而已。

最后，请刻意地去判断自己是否需要时间点恢复能力，因为它回答的是一种每日导出无法应对的故障。如果有人在 14:32 执行了一条破坏性查询，而你到 17:00 才发现，恢复昨晚的导出会丢掉整整一个工作日。持续归档则可以把日志重放到 14:31 为止。它需要更多存储空间，也带来相当可观的额外运维复杂度，所以它不该是默认选项——但对于任何一种“拥有写权限的人搞坏数据的速度，比你能察觉的速度还快”的场景来说，它就是一次事故和一场灾难之间的区别。

在数据离开之前先加密：restic、borg，以及那把你绝不能弄丢的密钥

让这份指南中其余一切都得以成立的那个特性，是客户端加密：数据在产生它的那台机器上，在任何一个字节跨越网络之前，就已经用一把目标端永远看不到的密钥完成了加密。就是这一个设计决定，把备份目标变成了不受信任的存储，而不受信任的存储可以放在任何地方——另一个国家的一台廉价服务器、一个对象存储、朋友的一台 NAS——而它们之中没有任何一个有能力读取你的数据。那些在服务端加密的服务商，保护你免受的是一组不同的、也窄得多的威胁，而这个差异恰恰在你购买离岸主机想要挺过去的那些场景中，最为要紧。

Restic 和 Borg 都能正确做到这一点，两者之间的取舍确实相当接近。Restic 是一个没有任何依赖的单一静态二进制文件，原生支持一长串后端——SFTP、兼容 S3 的对象存储、纯本地路径——而且在容器或最小化镜像里运行时，是两者中更省事的一个。Borg 是更老、在某些方面也更精细的工具，拥有更强的压缩选项、服务端出色的仅追加支持，以及一种许多人觉得更容易理解的仓库格式；它要求在通过 SSH 连接时两端都装有 borg，这是一个不起眼的限制，却偶尔会成为决定性因素。

不管你选哪一个，密码短语现在就是全部关键所在，值得像对待钱包助记词一样对待它。它绝不能只存放在它所保护的那台机器上——把密码短语和它所加密的数据放在一起，起不到任何保护作用，因为任何夺走服务器的场景，都会把密钥一并带走。把它放进另一台设备上的密码管理器里，或者写在纸上放在另一栋建筑里，最好两者都做。Borg 允许你把仓库密钥导出到单独的文件，restic 允许一个仓库携带多个独立密钥，这两种机制都能给你第二条进入的途径，不必依赖记住一个字符串。这件事没有恢复，没有重置链接，也没有哪张工单能够挽回：一个丢了密钥的加密仓库，和一堆随机数据毫无区别，而这正是它的全部意义所在。

值得明确说一下，为什么单纯用 rsync 同步到另一台服务器，替代不了备份，因为这正是大家第一个会想到的办法。Rsync 产生的是一份镜像，而镜像没有历史记录：今天删掉一个文件，今晚的同步就会忠实地把它也在那边删掉。它没有去重功能，所以想保留三十天，就意味着要存三十份副本，除非你在硬链接上耍些小聪明。它没有内置的静态加密，所以目标端能读到一切内容。而且除了重新读取源端之外，它没有任何校验手段。它是一种出色的传输方式，却是一份糟糕的备份，而这个区别，会在你需要三周前那个版本的那一天原形毕露。

仅追加，否则只是副本，而不是备份

这是决定架构走向的那个场景。有人拿到了你服务器的 root 权限——通过一个未打补丁的应用、一个泄露的令牌、一个变得心怀恶意的依赖包。他们现在身处一台机器内部，而这台机器握有通往自己备份目标的有效凭证，因为定时备份就是这么运作的。这台机器能删除的任何东西，他们都能删除，而删掉备份，在现代入侵手法里从来不是事后才想起的一步，它是第一步。即便没有攻击者，同样的道理也成立：一个出于好意、却带有一个失控变量的脚本，以 root 身份运行，完全有能力把一个仓库修剪得空空如也。

能够堵住这个漏洞的控制手段，是在接收端强制实施仅追加。这样配置之后，客户端可以创建新快照，却无法删除或改写旧快照——这个限制是由备份主机上的进程强制执行的，而不是靠客户端自觉。Borg 用 borg serve --append-only 来实现，并把它锁定在目标端 authorized_keys 里对应的那个密钥上，让客户端无法要求做任何别的事情。Restic 也有同样的形态，通过 rest-server 配合 --append-only 实现。在对象存储上，等价的做法是版本控制加对象锁保留策略，通过不同的机制达到同样的效果。

承载这一切的 SSH 配置值得不折不扣地弄对，因为它是那根承重的线。在备份用户的 authorized_keys 里，给客户端的密钥前面加上一个强制命令，以及 sshd 手册里记录的那些限制：command="borg serve --append-only --restrict-to-path /srv/backups/web01",restrict。仅这一行，就能让一把从客户端偷来的密钥无法打开 shell、无法转发端口、无法碰到另一台主机的仓库、也无法删除任何东西。给每个客户端都配上属于它自己的密钥和路径。

这就带来一个显而易见的问题：如果客户端永远无法删除，那谁来清除旧快照？修剪这件事发生在别处，按计划执行，使用的是那台受保护机器从未持有过的凭证。实际做法通常是：备份主机通过本地 cron 修剪自己的仓库，或者由第三台小机器持有那把特权密钥，每周执行一次保留策略。Borg 在这里有个众所周知的小麻烦——一个仅追加仓库的压实操作，必须在服务端而不是客户端运行——把备份主机当作保留策略的所有者，能干净利落地解决这个问题。这条原则可以推而广之：写入备份的机器，永远不应该是能够销毁备份的那台机器。

保留策略本身是个策略问题，有一个行之有效的常规答案：保留最近几份每日快照、四到五份每周快照，以及六到十二份每月快照。两个工具都支持以声明式的方式来表达这一点，你只需说明自己想要的形态，剩下的交给工具去判断哪些快照满足条件。真正能捕捉到缓慢损坏的，是这些每月快照，而它们也恰恰是仓库变大时人们最先砍掉的部分——这完全是本末倒置，因为一份几乎不怎么变化的数据集，经过压缩去重后的月度快照，成本几乎为零。

当没有人能确认你的身份时，第二份副本该放在哪里

“异地”这个词在 3-2-1 规则里承担着很重的分量，而对无需 KYC 的服务商来说，它的含义要比“另一栋建筑”具体得多。它指的是一份副本，其存续不依赖于和原件相同的公司、相同的账户、相同的支付关系，或者相同的法律管辖区。同一个账户下的两台服务器，不管数据中心相距多远，共享的都是同一个命运：账户因任何原因被关闭，会把两者一并带走；一份送达某个实体的法律文书，能触及该实体所持有的一切。独立性是一种关系属性，而不仅仅是地理属性。

这件事的实践版本比听起来容易，因为同一个控制面板已经提供了四个司法管辖区可选。在荷兰的一台生产实例，把仓库推送到冰岛的一个 Starter 档位，每月只要 $8.50，就能让你的恢复能力脱离任何单一国家程序的管辖范围——而且因为不同司法管辖区实际能抵御的东西各不相同，这个组合值得你花点心思去挑选，而不是随手抛枚硬币来决定。由于仓库在离开源端之前就已经加密，备份主机在设计上就是不受信任的：你用第二个地点买到的是可用性和法律距离，而不是保密性。保密性你已经有了。

要获得真正独立的第三份副本，最稳固的架构会把连接方向反过来。不再是服务器主动推送到一个它握有凭证的目标，而是由你控制的一台机器——家里的一台盒子、一台 NAS、一台按计划唤醒的笔记本电脑——主动从服务器拉取。这样一来，生产机器就完全不持有任何备份目标的凭证，这让上一节里的入侵场景在结构上就变得不可能发生，而不只是被削弱。代价是你需要一台必须按计划保持可达或处于唤醒状态的机器，这也是为什么它是对推送式异地副本的补充，而不是替代。

这类主机服务特有的两个约束条件，值得毫不修饰地讲清楚。它没有账户找回机制：没有身份证件可以出示，没有手机号码可以接收验证码，没有客服代表能替你确认“你就是你”。这正是你在注册时花钱买到的那个特性，而它是对称生效的——这就让密码短语和操作手册，在这里承担着一种在主流服务商那里根本用不上的承重作用。而且如果备份目标也需要付费，那也得匿名付费，否则第二份副本就会不声不响地，把第一份副本本该避开的身份关联重新引入进来。用同一个加密货币钱包支付两台机器的费用是没问题的；用银行卡支付备份的费用，则是一个决定，而不是一次疏忽。

演练，以及你要如何发现它已经失效

备份任务通常不会以轰轰烈烈的方式失败。它们是逐渐失效的：一次清理时把排除规则放宽了，凭证只在一端做了轮换，目标端磁盘被填满，一次发行版升级弄丢了一条 cron 记录。在上述每一种情况下，机器都照常运行，没有任何警报，仓库只是悄悄停止了增长。能捕捉到这一点的设计，不是对“失败”报警——一个不再运行的任务，没办法汇报自己的失败——而是对“没有成功”报警。让每一次成功运行都向一个 dead-man's-switch 端点发送一次 ping，并让那个端点在 ping 没有按时送达时发出警报。这只需要十分钟的设置，却是“一天之内就发现”和“恢复过程中才发现”之间的全部差距。

完整性校验是另外一半。两个工具都能校验仓库的元数据是否自洽，更有用的是，还能校验存储的数据块是否真的能解密、并且与其哈希值匹配。读取全部内容会消耗大量带宽，所以两者都提供了一种局部校验方式——restic 每次运行校验一定比例的数据，borg 按需校验数据——一个合理的节奏是：每周做一次完整的元数据校验，每月做一次局部数据校验，规模设定为一个季度能完成一整轮。存储介质确实会腐化，而校验的意义，就在于趁你手头还有另一份副本时，及时发现这一点。

以上这些都不能证明你真的能够恢复。这类证据只有一个来源，那就是真正去恢复一次。部署一个全新实例——最小档位只要 $8.50，而且你会在一个小时之内把它销毁掉——把仓库恢复进去，然后去做大家都会跳过的那一步：启动应用，查看真实数据。登录进去。打开上个月的一份文档。通过邮件服务器发一条测试消息。查询一张本该包含昨天数据行的表。文件是否存在，不是测试的重点；建立在这些文件之上的服务能否正常工作，才是。第一次搭建备份时就这么做一遍，之后再按一个你会真正遵守的日历周期重复做，因为这场演练同时也在验证操作手册，而操作手册过时的速度比数据更快。

操作手册值得单独用一段来讲，因为它是这里成本最低、却也最常缺失的一项。按顺序写下来：仓库存放在哪里、如何连接到它，密码短语保存在哪里，如何配置一台替换机器，需要安装哪些软件包和版本，要恢复什么、按什么顺序恢复，需要改动哪些 DNS 记录，以及如何确认恢复成功。把它保存在它所描述的那台机器之外——放在仓库本身里、放在密码管理器里、写在纸上——并且假定读它的人很疲惫，工作在一个不合时宜的时间点，而且很可能不是你本人。正是这最后一个假设，才能把一堆笔记，变成一份同事或家人也能执行的东西。

合在一起看，整套设计毫不起眼，而这正是它的优点所在：你的套餐已经包含的每小时快照，用来应对最近几天的意外；一个每晚推送到第二司法管辖区、在那里无法被删除的加密仓库；一个服务器从未见过的密码短语存放地点；一个在任务陷入沉默时会发牢骚的 ping；以及日历上的一场演练。清单上没有一项是困难的，大部分只需要一个下午，整套方案每月的花费，比你从零开始重建时顺手买的一杯咖啡还便宜。如果你现在就要动手搭建，第二台机器大约一分钟就能配置好——从那个你从未测试过的恢复开始做起，因为在这一切里，只有它才会告诉你真相。