如何把 VPS 备份到加密的离岸存储服务器

几乎没有人会在部署服务器的当天就把备份配好。这件事总是发生在事后——磁盘在一次升级中被填满之后，一次误删目录之后，一次迁移让数据库看似正常启动、实则答非所问之后，或者有人真的闯了进来之后。运行着一台要紧的机器，和手里握着一份能比它活得更久的副本，这两者之间的落差，是自托管里最危险的一段窗口期，而大多数人会在毫无察觉的情况下，在这段窗口期里住上好几个月——因为长时间什么都不会出错，然后所有事会在同一天一起出错。把这个窗口关上，既不难，也不贵。让它显得难的，是"备份"这个词同时被用来指四种不同的东西，而其中只有一种，会在最糟的那天依然还在。

不是备份的四样东西

下面每一样都真正有用，也值得拥有。但没有一样是备份，误以为它们是，是人们弄丢自以为安全的数据的头号原因。这个区分不是在抠字眼——它们每一个，都恰好会在你最需要备份的那种情况下失效。

• RAID 保的是在线率，不是备份。一个阵列能在一块盘物理损坏时不下线，这正是我们的存储服务器采用 RAID-6、能同时扛住两块盘故障的原因。但它扛不过一次目录删除、一次糟糕的升级、一棵被别人加密过的文件树，或者一张被删掉的数据表——这些改动，都会被原原本本地、在同一瞬间写进阵列里的每一块盘。
• 快照是撤销，不是备份。它们和数据本身存在同一块存储上，通常也在同一台机器上对 root 可见，任何摧毁了这个卷或这台主机的事故，都会把快照一起带走。回滚很快，但机器没了，它就什么用都没有。
• 同步是复制，不是备份。同步工具存在的意义，就是让远端和近端保持一致，所以一次删除或一次损坏，会以网络允许的最快速度传播到那份"副本"上。Nextcloud、Dropbox 和 rclone 的同步功能，设计上都是这样工作的。
• 版本历史和回收站是便利功能，不是备份。它们是应用自身的功能，数据存在应用自己的数据库里，保留窗口以天计。一旦坏掉的正是这个应用本身，它自己的历史记录也会跟着一起坏掉。
• 放在同一台服务器上的副本，算不上异地。如果出问题的是这台机器本身、主机商账户、hypervisor，或者是一次查扣，那么这台机器上的每一个文件，不管放在哪个目录，都处在同一个故障域里。

真正的备份，是一份在空间上、时间上、控制权上都各自独立的副本。空间独立，一场火灾或一次查扣才不会把两份一起带走。时间独立，你才能回到损坏发生之前，而不是回到损坏本身的一份忠实拷贝。控制权独立，从活跃机器上偷来的凭证才够不到它。这三条里少了任何一条，得到的都只是一个披着备份外皮的便利功能。

3-2-1 法则：撑到 2026 年的版本

老版本的法则是：数据留三份，用两种不同的存储介质，其中一份放在异地。这条法则一直没有过时，因为它讲的从来就不是磁带，而是"故障之间要相互独立"这件事。后来又多出两条，都配得上加进来——它们的存在，正是因为这条法则刚提出来的时候，还没怎么遇到过现在这些事。

• 三份数据。活跃数据本身，再加两份。只有两份，意味着再出一次故障你就只剩单点，而单点故障总有一种本事，会挑在你还没来得及修好第一个问题的时候发作。
• 两种存储介质。不同的硬件，不同的软件，理想情况下还是不同的主机商。同一台主机上的两个卷，共享同一个 hypervisor、同一个控制面板、同一个账户——也就是说，账户丢失的所有路径，它们也一并共享。
• 一份放在异地。物理上在别处，架设在一套不会跟着你的基础设施一起宕机的系统上。碰到火灾、盗窃、查扣，或者一次毫无预警的封号，真正有用的就是这一份。
• 一份不可变或离线。勒索软件和被攻破的 root 权限，都会第一时间去找备份下手，而一个你的服务器能写入的目的地，也就是它能抹掉的目的地。只追加凭证，或者一套拉取式的架构，能把这变成一次麻烦，而不是一场灾难。
• 零份未经验证的备份。一份你从没恢复过的备份，只是一个假设。这一条是人们最常跳过、事后也最后悔的一条——因为一个连续两年都报告"成功"的备份任务，完全可能已经连续两年，都在写一堆根本没法用的归档。

该备份什么：是状态，不是整台机器

本能的做法是把整台服务器打成镜像。这通常是错的思路：镜像备份体积大、速度慢，想单独恢复某一部分也很别扭，而且里面大部分内容，都只是一个几分钟就能重装出来的标准操作系统。真正无法重新生成的，是"状态"——那些只因为你做过什么，才存在的东西。

• 数据库，要导出，不要直接复制。在引擎还在写入的时候复制一份数据库文件，得到的是一个撕裂的文件——它可能能恢复，也可能恢复出错，而且不会告诉你到底是哪一种。要用引擎自带的导出工具，或者先停服务，或者打一个文件系统快照再从快照里导出。
• 应用的数据目录。上传的文件、媒体、生成的资源——也就是数据库指向的那棵文件树。它必须和对应的数据库在同一个时间点上一起被采集，不然恢复出来的，就是一份描述着一堆不存在的文件的索引。
• 配置，以及你手动改过的那些东西。Web 服务器和反向代理的配置、systemd 单元、cron 条目、防火墙规则，还有你凌晨两点顺手改掉的那二十个小问题——事后你不会记得它们。
• 密钥与凭证，需要单独、更谨慎地处理。TLS 证书及其私钥、SSH 主机密钥、API 令牌，最重要的是钱包文件和助记词。它们值得拥有一份专属的加密副本，而且不能只放在一台租来的机器上。
• 容器定义与数据卷。compose 文件和环境变量文件，加上具名数据卷——这是人们最常忘掉的一块，因为容器本身重建起来毫不费力，但它的数据卷不会自己重新出现。
• 装了什么的清单，而不是安装本身。一份简短的软件包、版本号，以及各自跑在哪里的清单，恢复起来比整个根文件系统的镜像更快、也更小。

分界线很简单：如果一样东西能靠一个脚本或者包管理器在十分钟内重新生成，就不用备份它——把方法记下来就够了。如果它的存在完全是因为你或者某个用户做过什么，那它就需要一份副本。这条原则，从一个小站点，一路适用到一个 BTCPay 实例——那里钱包和数据库就是一切，其余部分都能重装——再到一台 Nextcloud 服务器——那里文件树和它的数据库必须一起被采集，否则单独留下哪一个都没多大意义。

给目的地估算容量：它到底要花多少钱

人们普遍严重高估这笔开销，算法通常是：先给第一次全量备份定个价，再乘以打算保留的天数。但现代备份工具根本不是这样工作的。它把数据切成块，每一个不重复的块只存一次，能压缩的就压缩——所以一台大部分内容都没变的服务器，第二次快照几乎不花什么额外空间，三十份每日快照，离"第一份的三十倍"差得很远。

• 按典型保留策略、一台变化速度正常的服务器来算，预算大致留出与活跃状态相当的容量，再加三成到五成给历史版本。
• 决定容量增长的，是保留期，而不是备份频率。保留两天的每小时快照，比保留三年的每日快照更便宜。先想清楚你实际上最多会往回找多久，然后按这个期限自动修剪。
• 已经压缩过的数据不会被二次压缩。视频、照片、压缩包和加密数据块，占用的空间都接近原始大小，所以一台以媒体为主的服务器需要的是实打实的容量，而不是靠配置取巧。
• 数据库导出文件之间的去重效果通常很差，因为哪怕数据库只有细微差异，压缩之后的导出文件也会是完全不同的字节流。导出时不要压缩，把压缩交给备份工具去做，存储成本会明显降下来。
• 慢的只有第一次上传。在那之后，每晚的任务只需要传输增量，在大多数服务器上也就是几 MB 的量级。这里的流量不限量，所以第一次全量上传，考验的是耐心，不是预算。

实际算下来，这是你整套技术栈里最便宜的一份保险。存储服务器从 $7.99/mo 起，给你 1 TB 的 RAID-6 空间——这已经比一小批 VPS 实例的状态数据加起来还要多，STO-2 以 $12.99/mo 把容量翻倍。真正需要在意容量的，是媒体库和长保留期这类场景：STO-4 以 $22.99/mo 给到 4 TB，STO-8 以 $39.99/mo 给到 8 TB。目的地支持 rsync、SFTP 和兼容 S3 的 API，所以主流备份工具不用装插件就能直接对接，卷在静态存储时以 AES-256 加密，也支持自带密钥——不过下一节会讲到，无论如何，你都应该在数据离开源头之前，就把它加密好。

怎么选工具：每一款到底是为什么而生的

这里不必纠结太久。三款工具基本覆盖了所有场景，全都免费，而它们彼此之间的差异，远不如"用不用"这件事本身重要。按你问题的形状去选，而不是按跑分去选。

• restic——大多数服务器的默认推荐。客户端加密、自动去重、单个静态二进制文件、不需要常驻进程，能原生写入 SFTP、兼容 S3 的端点和普通目录。它的只追加模式，是通向"一个被攻破的服务器也抹不掉"的目的地最简单的路径。
• BorgBackup——去重和压缩效果都很出色，在慢速链路上效率很高，成熟且久经验证。远程仓库需要目的端也装好它自己的程序，这是一个不大的限制条件，换来的是明显更省存储空间。
• rclone——当你要做的其实是在对象存储之间搬数据，或者想要一份镜像而不是带版本历史的备份时，它才是对的工具。如果直接拿它来用，记得配上它自带的加密层，也别忘了普通的同步会把删除操作一起传播过去。
• 数据库永远用原生的导出工具。mysqldump、pg_dump 以及它们的同类，产出的是一份引擎自己肯定读得回去的、一致的逻辑副本。先导出成文件，再交给 restic 或 Borg 去处理这个文件——不要试图用什么取巧的文件级复制去替代导出这一步。
• 主机商提供的快照，只当作一层快速的本地手段。在有风险的升级前后拿它做快速回滚就好，但永远不要把它算作你三份副本里的一份。

分步指南：一次坐下来，配出一套能用的加密备份

1. 01先部署目的地，并把它锁好选一台和它要保护的服务器不在同一地区的存储服务器。只用密钥登录的 SSH，专属的用户账号，且不与将要写入它的那些机器复用任何凭证。
2. 02先列出状态清单，再碰任何工具把每一个必须留存下来的路径和数据库都写下来。现在花十分钟写一个文本文件，能避免日后恢复时才发现，有个目录根本没人写进清单里。
3. 03初始化一个加密仓库生成一个强密码作为仓库密码，通过 SFTP 或 S3 初始化仓库，并把这个密码存在被备份的那台服务器以外的地方。一个密钥只存在于已经报废的机器上的仓库，是没法恢复的。
4. 04先导出数据库，再打包归档写一个包装脚本，先把每个数据库导出到一个暂存目录，再对导出文件和文件树一起跑一次备份。正是这个先后顺序，让数据库和它的文件彼此保持一致。
5. 05跑第一次备份，并守着它跑完第一次是最耗时的一次。放在终端复用器里跑，这样断线也不会把它杀掉，同时记下它花了多久——这也就顺带让你知道了你的恢复窗口有多长。
6. 06设置保留策略，并自动修剪大致保留七份每日快照、四份每周快照、六份每月快照，适合大多数服务器。把修剪配置在同一个任务里，不然仓库只会一直变大，直到某天彻底跑不动。
7. 07把它排进日程，并让失败发出声音一个每晚触发的定时器或 cron 条目，加上一条"任务没有报告成功"就会触发的告警。一个悄无声息的备份任务，在你察觉之前的那几个月里，和压根没有备份没什么两样。
8. 08今天就从备份里，在另一台机器上恢复点什么不是列出归档里有什么，而是把一个真实文件和一个真实数据库，实实在在地恢复到一台临时机器上。在你亲手做过这一次之前，你手里的只是一个备份脚本，不是一份备份。

让副本扛过杀死服务器的那件事

这一部分，决定了备份对攻击者来说，究竟是"真正的备份"还是"一点小麻烦"。如果服务器手里握着能删除备份的凭证，那么一次 root 被攻破、一次勒索软件发作，或者一个跑坏的脚本，都能在同一分钟内同时殃及两份副本。解决办法是结构性的，不是靠把密码设得更复杂。

• 从源头开始，就只用只追加凭证。restic 和 Borg 都支持这样一种模式：负责写入的机器能创建新快照，但删不掉、也修剪不了已有的快照。修剪则改由别的地方、按计划、用另一把密钥来执行。
• 能用拉取式架构就优先用。让目的地主动伸手去源端取数据，而不是源端主动推送——这意味着源端自始至终都不掌握归档的任何访问凭证。
• 不要在多台服务器之间复用 SSH 密钥或仓库密码。一台机器被攻破，代价应该只是这一台机器的备份，而不是你名下的整片资产。
• 至少留一份副本，放在不同的司法管辖区、不同的故障域里。地区上的分散不是庸人自扰——它是"一次硬件故障"和"彻底全丢"之间的全部差别。
• 把仓库密钥，完全存放在这套基础设施之外。密码管理器、硬件密钥、保险箱里的一张纸——除了仓库自己保护着的那些机器，放哪儿都行。
• 留意那些突然快得可疑的"成功"备份。一个原本要跑二十分钟的任务，忽然四十秒就跑完了，通常是在备份一个空目录或者一个已经掉了挂载的目录——而它还会一边这么干，一边继续向你报告成功。

在这里，地区选择是一个真正的决定，而不是一个细节，因为你的备份和你的生产服务器，不应该能被同一次行动一起查扣。如果这对你所跑的东西来说很重要，刻意去挑一个地区值得花上几分钟，而把目的地放在和源端不同的法律体系下，正是这么做的意义所在。

恢复：那个没人会提前演练的环节

恢复失败的原因往往很平淡，而它偏偏总在最糟的那一刻失败——因为对大多数人来说，那也是他们唯一一次真正尝试恢复。下面这些失败，如果是在一次演练里，几分钟就能发现；如果是在一次真实故障里，则要花上好几个小时。

• 仓库密码只存在那台已经报废的服务器上，于是归档本身完好无损，却永远也打不开了。
• 数据库恢复成功了，但文件树用的却是三小时之后那次任务的版本，于是应用里显示的记录，指向的文件根本不存在。
• 备份采集的那个目录，早已悄悄掉了挂载，于是它整整一年，每晚都尽职尽责地把一个空文件夹归档了一遍。
• 没人知道该按什么顺序恢复——先数据库还是先文件、服务该停着还是开着——结果一个恢复到一半的状态只能推倒重来。
• 按现有链路的速度，恢复要花十一个小时，而这个数字从没人实际测过，恢复计划里假设的却是快得多的另一个数字。
• 文件的属主和权限恢复错了，于是所有文件都在，应用却死活起不来。
• 被测试过的，永远只有最新的那份快照，而这一次要恢复的损坏，其实是六周前就已经开始的。

一年演练两次，就能把这些问题全部解决。开一台用完就扔的VPS，从真实仓库恢复到上面，把服务启动起来，看看数据对不对，再销毁这台机器。前后也就几美元、一个小时，却能把整套备份系统，从一个"我相信"，变成一个"我确认过"。照着操作手册跑一遍，手册在哪里骗了你，就把哪里改掉。

隐私这一层：一份备份能亲手拆穿你的匿名

这一节是离岸自托管特有的问题，也只有在第一次上传之前就想清楚，才容易做对，事后再补就难了。一份备份，是你整套基础设施完整、带索引、长期存在的一份拷贝，放在别的地方——这让它的敏感程度和源头本身完全一样，却比源头更容易被人忘在脑后。

• 就算内容已经加密，文件名和目录结构本身依然是元数据。restic 和 Borg 的客户端加密，连名字也会一起加密；普通的 rsync 镜像不会，而单单一份目录列表，往往就足够让人猜出这台服务器是干什么的、又是谁在运营它。
• 目的地那个账户，本身就是故事的一部分。用你本人名下的信用卡租来的备份仓库，会把这个名字和仓库里存的一切绑在一起——不管源端那台机器打理得多干净，都没用。
• 备份流量，是两个地址之间一条持续的、按计划触发的大流量连接。这是一台服务器会产生的、最容易被读出规律的模式之一，而且它每天晚上都在明明白白地指向目的地。
• 旧快照会比当初促成它们的那些决定活得更久。一年前你就已经不再存放的东西，只要保留策略没把它修剪掉，它依然躺在归档里——这对恢复来说是好事，对暴露风险来说却不是。
• 日志和 shell 历史，会和别的东西一起被顺带扫进备份。归档里经常装着那些你在活跃机器上一直小心提防的 IP 地址、命令和凭证。

解决办法都很寻常。用一款连名字也一起加密的工具。用你租源端服务器的那一套方式去租目的地——找一家从没问过你叫什么名字的主机商，用加密货币余额付款；如果你还想把支付这条线也切干净，就用门罗币充值。如果连流量模式本身都让你不放心，就把传输过程路由进一条 WireGuard 隧道。并且把你用在生产服务器上的那套头十分钟加固，原样用在这台存储机器上——因为一台存着"万物拷贝"的机器，价值不会比源头更低，很多时候反而更高。

会让人赔上数据的那些错误

• 把 RAID、快照或者一个同步文件夹当成备份来信任，直到关键的那天，才发现它们各自其实属于哪个类别。
• 唯一的一份副本，和被保护的那样东西放在同一台服务器、同一个账户，或者同一家主机商那里。
• 直接复制一份还在运行中的数据库文件，而不是导出它，结果恢复出来的归档，带着一种不容易察觉的、悄无声息的错误。
• 在不同的时间点分别备份文件树和数据库，导致恢复时两者对不上。
• 把仓库密码，存在这个仓库自己正在保护的那台机器上。
• 给源端在目的地上完整的删除权限，导致一次入侵就能把归档一起带走。
• 从不修剪，直到目的地被塞满，而每晚的任务其实已经悄悄失败了好几个星期。
• 把几百 GB 公开的区块链数据备份了一遍又一遍，而钱包文件却根本没出现在任何一份归档里。
• 只给"失败"配了告警，却没给"任务干脆没跑"配告警，于是一个彻底停摆的任务，什么动静都不会有。
• 只测试过最新的那份快照，直到一次真实事故发生，才发现损坏其实比这份快照更早就开始了。

备份是你会配置的东西里最无趣的一个，却也是唯一一个，一旦缺失就无法挽回的一个。服务器上别的一切，都能靠一个包管理器和一个下午重建出来；状态不能。花一次坐下来的时间，把它一次做完：列出必须留存的东西，导出数据库，把加密归档发到另一个国家的一台存储服务器上，按计划自动修剪，在它沉默时发出告警，并且在关掉终端之前，真的恢复一样真实的东西出来。然后就不用再管它了。一套好的备份系统，衡量标准就是你会把它忘掉——直到某天早上，它把一场灾难，变成了不过是有点烦人的一个小时。