VPS 加密备份。
异地存储，已去重，无法触及。

几乎每一场关于备份的争论，都在第一分钟就跑偏了，因为对话双方脑子里想的是不同的失效场景。一个人想的是硬盘报废，另一个人想的是某个周二早上账户突然没了。这两种情况需要不同的答案，而一个只扛得住第一种的方案，会一直感觉很安全，直到被第二种情况真正考验为止。

有四种值得专门设计应对方案的失效模式，它们并非同一主题的变体——每一种都会击溃一种不同的防御手段。

硬件。 NVMe 故障、宿主节点宕机、阵列同时损失两个成员。这是人人都会为之做准备的失效场景，也是现代虚拟化基础设施上最罕见的一种。冗余存储能应对它。除此之外冗余存储什么也应对不了，这正是 RAID 从来都不是备份的原因：它会忠实地复制每一次写入，包括那条写着「删除一切」的写入。

人为。 在生产环境上跑错的迁移脚本。在错误的终端里执行的 DROP TABLE。参数写反的 rsync。这是目前为止造成真实数据丢失最常见的原因，而唯一的防御手段是历史记录——一份保存在错误发生之前、且错误没有波及到的副本。关键的成分是时间：如果唯一的副本只是一个落后三十秒的镜像，它早已包含了这个错误。

恶意。 有人拿到 root 权限，或者勒索软件通过一个未打补丁的应用侵入。现代勒索软件做的第一件事就是寻找备份配置——凭据、挂载的共享、云端密钥——并将找到的一切摧毁，原因很简单：一次有效的恢复能把一场灾难变成一个下午就能解决的小事。一个能删除数据的备份凭据，就是攻击者继承来的凭据。本指南中关于仅追加的章节，正是为应对这种失效而存在的。

托管方。 没有任何东西损坏，也没有遭到任何攻击；你只是失去了访问权限。一次由自动欺诈信号触发的封号、一次出差途中银行卡扣款失败、一场纠纷、一次合规审查、一份送达服务商的法律命令。机器完好无损，却无法访问，而该账户里的每一份快照也随之一起无法访问。这种失效，无论在同一家服务商内部堆砌多少冗余都无法应对——这正是一份严肃的备份必须放在另一个屋檐下的原因。

最后一行正是本指南接下来要搭建的目标。它并不比上一行更贵——仅追加设置是免费的，第二个法域的费用和第一个一样，同样是 $3.90。

3-2-1 法则，针对单台 VPS 重新表述。 三份数据副本，存放在两种不同的存储介质上，其中一份放在异地。这个经典表述来自磁带和办公室服务器的时代，其精神比字面表述更经得起翻译。对于一台自托管的机器，它的意思是：VPS 上的在线数据，另一台机器上的一个仓库，再加上——对于真正无可替代的东西——一份你能亲手掌握的第三份副本，放在家里的硬盘上，或者抽屉里。真正重要的数字并不是「三」，而是需要多少个相互独立的环节同时出错，数据才会真正丢失。「二」是值得拥有的最低限度。

备份整个文件系统是一个说得过去的选择，但也是一种浪费。服务器的大部分内容，只需一条包管理器命令就能重新生成，而你多背负的每一 GB，都会让仓库清理变慢、存储成本变高、在你急需时搜索也更慢。真正有用的做法正好相反：列出一份全新安装无法帮你找回的东西清单。

对于一台典型的自托管 VPS，这份清单并不长，而且总是包含以下这五样东西：

• 01数据库内容。 不是数据目录——是转储。步骤 05 会说明原因。
• 02用户上传的文件。 Docker 卷、上传或媒体目录、邮件存储。这些通常占了大部分体积。
• 03配置文件与密钥。 Compose 文件、.env 文件、加密密钥、API 令牌。体积很小，却决定了恢复是花两小时还是两天。
• 04你已修改过的系统状态。 /etc 整体很小，完全可以整体纳入——sshd 配置、防火墙规则、systemd 单元、cron 条目，还有你花了一整晚配置的邮件路由。
• 05任何绑定了身份信息的东西。 Tor 隐藏服务密钥、Matrix 签名密钥、WireGuard 私钥、一个节点钱包。丢失其中任何一个，服务都不会真正恢复——恢复的只是一个同名的不同服务。

把这份清单在源服务器上变成两个文件。包含列表让意图一目了然；排除列表则把噪音挡在外面。两者都会被备份命令读取，而且两者本身也都应该被纳入备份。

/etc/backup/include.txt

/etc
/opt
/root
/var/backups
/var/lib/docker/volumes
/home

/etc/backup/exclude.txt

# Caches and rebuildable artefacts
**/node_modules
**/.cache
**/*.tmp
/var/lib/docker/volumes/*/_data/cache
# Log noise — keep the config, drop the volume
/var/log/journal
# Never back up the mount point you restore into
/mnt/restore

关于那一行 Docker 命令，有两点需要说明，因为很容易让人栽跟头。命名卷位于 /var/lib/docker/volumes 之下，这正是你需要的；绑定挂载则位于你自己指定的位置，通常就在 Compose 文件旁边，被 /opt 覆盖到。容器镜像不是数据——它们只需一条 pull 命令就能找回，把它们也纳入备份，只是在白白搬运用不上的若干 GB。

最后，在围绕这个数字搭建任何东西之前，先把它测出来。这个数字会告诉你该订哪一档仓库，也会告诉你第一次运行是要四分钟还是四十分钟：

du -sh --exclude=/var/lib/docker/overlay2 /etc /opt /root /home /var/lib/docker/volumes

仓库主机只有一项任务，几乎没有别的要求。它不需要核心数，因为它从不读取你的数据——它保存的是自己也打不开的加密数据块。它不需要内存，因为去重工作是在源端完成的。它需要的是磁盘、一个稳定的地址，以及一个源机器的麻烦不会波及到的地方。

在控制面板中：Order → VPS → Sentinel，镜像选 Debian 12，以及——这才是重点——选一个与源机器所在堡垒不同的堡垒。Helsinki 负责运行，Reykjavík 负责保存。开户不需要邮箱地址，账单可用 Monero、Bitcoin、Lightning 或其他支持的资产结算，这意味着第二台机器不会重新暴露第一台机器一直小心保护的身份信息。

「工作集」这一列假设的是正常变化频率下、保留一年的每日快照；如果仓库主要存放变化缓慢的文件，实际能撑得更久，如果里面全是被反复重写的大型二进制文件，则撑不了那么久。最后一行是为了体现规模，也是为了提醒一个人们总要到倒霉那天才想起的细节：对象存储的下载同样要收费，而下载正是你在紧急情况下要做的事。

在目标端——一个无特权用户，加一个目录。

adduser --disabled-password --gecos "" backup
install -d -m 0700 -o backup -g backup /srv/restic/web01

备份用户没有密码、没有 sudo 权限，也没有任何可登录的入口。它存在的唯一目的就是拥有一个目录。如果你要备份多台源机器，就给每台机器分配各自独立的目录——每个源对应一个仓库，能确保一台机器被攻破不会波及另一台的历史记录。

在源端——一把不做他用的密钥。

ssh-keygen -t ed25519 -f /root/.ssh/id_backup -N "" -C "backup:web01"
cat /root/.ssh/id_backup.pub

不要复用你的登录密钥。这把密钥会以未加密的形式留在磁盘上，因为凌晨三点要由一个无人值守的定时任务使用它——这正是你需要把用途限定在单一目标、单一用途上的那种密钥。

回到目标端——限制这把密钥能做的事情。 将公钥粘贴到 /home/backup/.ssh/authorized_keys 中，并在其前面加上一个前缀。对于通过 SFTP 使用的 restic：

restrict,from="198.51.100.7" ssh-ed25519 AAAAC3NzaC1lZDI1... backup:web01

restrict 选项一次性关闭端口转发、代理转发、X11 和 PTY 分配，只留下文件传输功能，别无其他。from= 子句将密钥锁定在源地址上，因此即使这把密钥从服务器上被窃取，在其他地方也毫无用处。对于 Borg，可以更进一步，强制指定命令，仅追加模式正是由此实现的：

command="borg serve --append-only --restrict-to-path /srv/borg/web01",restrict ssh-ed25519 AAAAC3NzaC1lZDI1... borg:web01

这一行就是整套勒索软件防御的核心：无论源端发来什么，目标端始终只会运行 borg serve，只在那个路径内，也只以追加模式运行。源端就算拿到 root shell，也无法用这把密钥抹掉上个月的数据。

在源端把目标地址命名一次就够了。 将其写入 /root/.ssh/config，这样之后的每条命令都会很短，地址也只存在于一个文件中：

Host rkv-repo
    HostName 198.51.100.42
    User backup
    IdentityFile /root/.ssh/id_backup
    IdentitiesOnly yes

然后手动连接一次——ssh rkv-repo——以接受主机密钥。无人值守的定时任务不会回答指纹确认提示，第一次备份悄无声息地卡住一整周是个经典案例。趁你还在目标端，就把它当作你拥有的任何其他机器一样对待：在它上面也运行一遍首小时加固清单。它保存着一切的副本，值得花上完整的一小时。

数据库规则，只讲一次。 一个正在运行的数据库引擎把状态保存在内存中，并按自己的节奏写入磁盘。在它这样做的同时读取它的文件，你得到的会是来自好几个不同时刻的一组页面——这样的文件可能可以恢复，可能恢复后是损坏的，也可能恢复出一个能正常打开、却悄悄缺了最后一小时数据的东西。从外部根本无法分辨会是哪一种。所以备份从不触碰在线文件：先把转储写入磁盘，备份再去取这份转储。

所有内容都写进一个脚本。把它放在 /usr/local/sbin/nb-backup.sh，赋予可执行权限，并且把这个脚本本身也纳入备份：

#!/bin/sh
set -eu

# ---- 1. Consistent dumps, written where the include list will find them.
install -d -m 0700 /var/backups/db

# PostgreSQL in a container:
docker exec -t app-db pg_dumpall -U postgres | gzip -9 > /var/backups/db/postgres.sql.gz

# MariaDB / MySQL, InnoDB tables:
# docker exec -t mail-db mariadb-dump --single-transaction --all-databases \
#   | gzip -9 > /var/backups/db/mariadb.sql.gz

# SQLite — never a plain file copy:
# sqlite3 /opt/app/data/app.db ".backup '/var/backups/db/app.db'"

# ---- 2. The snapshot.
restic backup \
  --files-from /etc/backup/include.txt \
  --exclude-file /etc/backup/exclude.txt \
  --tag nightly --one-file-system

# ---- 3. Retention, then reclaim the space it freed.
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

# ---- 4. Structural check every night; read 5% of the data on Sundays.
restic check
[ "$(date +%u)" = "7" ] && restic check --read-data-subset=5%

echo "backup ok: $(date -u +%FT%TZ)"

那段脚本里有三个细节，起的作用比看上去要大。开头的 set -eu 意味着一次失败的转储会直接中止运行，而不是悄无声息地在接下来六个月里一直快照昨天那份旧转储。forget 和 prune 合并成一条命令，因为一个从不释放空间的保留策略，最终只会是一块被填满的磁盘。而周日的检查读取的是实际数据的一部分，而不只是索引——仓库损坏很少见，而且是无声的，唯一能发现它的办法就是去读取数据。

定时任务。 两个小小的 unit 文件。这里应该用 systemd 而不是 cron 作调度器，因为定时器能给你 Persistent 选项——机器关机期间错过的一次运行，会在下次开机时补上，而不是悄悄被跳过——而且 journalctl 会保留每一次运行的历史记录。

/etc/systemd/system/nb-backup.service

[Unit]
Description=Nightly encrypted offsite backup
Wants=network-online.target
After=network-online.target docker.service

[Service]
Type=oneshot
EnvironmentFile=/etc/backup/restic.env
ExecStart=/usr/local/sbin/nb-backup.sh
Nice=10
IOSchedulingClass=idle

/etc/systemd/system/nb-backup.timer

[Unit]
Description=Nightly encrypted offsite backup

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=45m
Persistent=true

[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now nb-backup.timer
systemctl list-timers nb-backup.timer
systemctl start nb-backup.service && journalctl -u nb-backup.service -n 40 --no-pager

随机延迟不是摆设。互联网上几乎每台自托管服务器都恰好在 03:00 执行维护任务，如果备份和日志轮转、证书续期、容器更新在同一秒启动，整晚就会为争夺 I/O 而互相拖累。把启动时间分散在四十五分钟内不花一分钱，却能消除一整类莫名其妙的慢夜。

然后，让失败不再无声无息。 这是人人都会跳过的一步，却决定了前面做的一切是否有意义。一个停止工作的备份不会发出任何提示：定时任务照常触发，服务照常运行失败，最后一个可用快照渐渐成为过去，而仪表盘依然显示一片绿色。给这个服务加上一个 OnFailure= 单元，让它真正把消息发到你能看见的地方，并且每月扫一眼快照列表的最上面几条。一行配置，一个习惯。

restic snapshots --latest 3        # is the newest one from last night?
systemctl list-timers nb-backup.timer   # is the timer still armed?

到目前为止的一切，防的都是意外。这一章要防的是对手，而这个设计问题一旦看清楚就会让人不太舒服：源机器每晚都要连上仓库，这意味着源机器上保存着一份能用的仓库凭据。谁拿下了源机器，谁就拿到了这份凭据。如果这份凭据能删除数据，攻击者就会删除——现代勒索软件正是故意这么做的，而且是在加密任何东西之前先做，因为一个能恢复的受害者是不会付钱的。

解决办法不是用更强的密码，而是一种非对称权限：源端可以新增数据，但不能删除任何数据。有三种实现方式，按上手难度从易到难排列。

第一种——通过 SSH 强制仅追加写入。 这是 Borg 的主场，也是在你自己拥有的机器上能得到的最干净的答案。第 03 步中 authorized_keys 里的那一项强制执行 borg serve --append-only，因此无论源端提出什么请求，目标端都会拒绝删除。清理仍然需要进行，但要从目标端发起，按源端无法影响的计划执行，由源端触及不到的账户运行。攻击者即便在源端拿到了 root 权限，也只能往仓库里塞垃圾数据；他们无法删除攻击发生前一晚的归档。

第二种——仅追加的 REST 端点。 restic 配套的 rest-server 也有一个 --append-only 模式，性质相同：接受新的数据块，但无法删除已有的。把它运行在目标端并置于 TLS 之后，将 RESTIC_REPOSITORY 指向 https:// 地址而不是 sftp: 地址，防御的形态就完全一样了。代价是目标端多跑一个服务，换来的是相同的保障。

第三种——对象锁定。 在 S3 兼容存储上，版本控制加上对象锁定保留期，能在保留期到期之前让删除操作彻底无法执行，这是由存储层强制保证的，而不是靠某个程序。这是三种方式里最强、也最贵的一种，而且它会引入一个服务商账户——这又带回了本指南通篇都在设法分散的托管方风险。作为第三份副本，它很合理；作为唯一的一份，就显得别扭了。

如果以上都不适用——只有普通 SFTP，一把能写入、因此也能删除的密钥——就不要自欺欺人；另外加一份源端完全碰不到的独立副本。用拉取代替推送：让目标端登录到源端，读取所需内容并保存下来。凭据这时就保存在没有暴露的那台机器上，攻击者即便拿下了源端，也找不到任何指向备份的线索。搭建起来会多花一点功夫，但恰好把风险扭转到了正确的方向。

无论你选择哪一种，都要用验证任何其他安全控制手段的方式去验证它——尝试把它攻破。从源端，用备份密钥，尝试执行一次删除。正确的结果应该是被拒绝。

borg delete ::name-of-an-old-archive
# → Remote: Repository is in append-only mode. Refusing to delete.

问大多数人为什么备份要放在别处，得到的答案是火灾、水灾，或者数据中心断电。这些都对，也都越来越罕见，而且只需要 100 公里的物理距离就能应对。真正在 2026 年拖垮企业的失效，是行政性的，仅靠物理距离对此无能为力。

一个账户，就是一个单点故障。 一次自动欺诈信号触发的封号，一次发生在你坐飞机时的拒付，一场合规审查，一份寄给公司而非某台机器的下架通知——这些情况无一例外会在同一时刻波及该账户下的每一台服务器，包括保存着快照的那一台。技术上的冗余再完美，也与此无关。两家服务商，或者至少两个分属不同法律主体的账户，才是唯一能应对这种情况的结构。

一个法域，就是一套法律框架。 北欧四大堡垒并非可以互换——瑞典、芬兰、挪威和冰岛各自保护的重点略有不同，而挪威和冰岛完全不在欧盟范围内。把工作机器和它的仓库分置在其中两地，意味着副本不只是换了个地方，而是处于另一套独立的规则之下。北欧法域参考逐条梳理了相关法规。

而目标端对此一无所知。 正因如此，这种拆分是划算的，而不是一种取舍。restic 和 Borg 都会在数据离开源端之前完成加密，所以仓库主机存储的是它没有密钥可以打开的数据块。它不知道自己保存了哪些文件、有多少个文件，也不知道文件叫什么名字。你不是在把信任交给第二方，而是在租用一块连自己都读不了的磁盘。这也是「我该不该用一个我并不完全信任的服务商作为备份目标？」这个问题最诚实的答案——对一个加密仓库来说，信任几乎无关紧要。

延迟并不是问题。 Helsinki 到 Reykjavík 骨干网延迟是 30 ms，Helsinki 到 Stockholm 是 8 ms，Stockholm 到 Oslo 是 11 ms。每晚一次的备份根本不在乎这些数字，受限于磁盘吞吐量的恢复过程也一样不在乎。选这对组合要看法律距离，而不是网络距离——在北欧范围内，网络距离几乎可以忽略不计。

还有一件事值得直说，因为这正是本指南会出现在这个网站上、而不是出现在一个普通系统管理博客上的原因：第二台机器会把第一台机器已经解决过的每一个问题重新打开一遍。如果工作用的 VPS 是无需身份证件、用 Monero 支付订购的，而它的备份机却是用公司信用卡加护照扫描件订购的，那么这一对机器的可识别程度，就等同于其中较弱的那一半。匿名 VPS 托管主题指南详细讲解了三个层面——注册、付款、网络——它们对备份目标的适用程度，和对一台 Web 服务器完全一样。