异地备份
为什么与数据放在一起的副本救不了您，该把备份放到哪里，如何限制密钥权限，以及当机器完全不可用时应该还能访问什么。
更新于 2026年8月23日
同一块磁盘上的副本只能防住一件事——您自己误敲的 rm -rf。只有位于另一位置的副本，才能让您免于系统重装、失去访问权限、勒索软件，或任何导致整台机器瘫痪的故障。
在哪里做副本
| 位置 | 优点 | 需要注意 |
|---|---|---|
| 第二台 VPS | 完全可控，链路快 | 两台机器在同一家服务商——风险共担 |
| 家用电脑或 NAS | 便宜，物理隔离 | 需要固定地址，或由家庭侧主动发起连接 |
| S3 对象存储 | 无需维护，按量付费 | 恢复时留意出站流量费用 |
| 支持 SFTP 访问的独立存储 | 简单，大容量时便宜 | 存储侧通常没有版本控制 |
原则很简单：副本必须在源机器完全损毁后依然存在。如果一次事件就能让两处存储同时挂掉，那您其实只有一个位置。
谁从谁那里拉取
有两种方案，它们对勒索软件的防护效果不同。
由机器推送副本。 简单，但推送密钥就放在这台机器上。攻击者拿到 root 权限后，同样能接触到存储。
由存储侧主动拉取副本。 密钥放在接收端，机器对它一无所知。更安全，但要求接收端能够访问到这台机器。
兼顾两者的折中方案：由机器推送，但接收端的密钥被限制为只写，没有删除权限。
command="rrsync -wo /srv/backup/vds",restrict ssh-ed25519 AAAA... vds-backup
在 Restic 中，同样的角色由 append-only 模式承担——一个只能追加的仓库：
restic --repo sftp:backup@host:/srv/restic backup /data
这种情况下，由接收端按自己的计划删除旧快照，而不是由机器来删。
一把放在机器上、且有权删除副本的密钥，会让整套方案大打折扣。勒索软件首先找的就是这把密钥。删除权限必须属于别人。
可用性检查
您往往会在最糟糕的时刻需要恢复：机器宕机，您手忙脚乱，没有时间。请提前确认您手头有：
- 存储地址和凭据——记录在这台机器之外。
- Restic 仓库密码——放在密码管理器中。
- 机器的 root 密码——它以加密形式存储，通过
/hosting/vds/m/<id>面板“访问”标签页中的按钮显示，但该面板只有您能访问。 - 一份清单，写明什么在哪里：哪个副本里有什么。
把这些写成一则简短的备忘，并保存在 VPS 之外。
要传输多少数据
带宽最高可达 500 Mbps，但瓶颈通常在接收端。首次完整复制请手动进行，并选择空闲时段；之后只会传输变更部分。若要限制速度以免影响服务：
rsync --bwlimit=10000 ...
restic backup --limit-upload 10000 ...
数值单位为千字节每秒。
常见错误
- 两份副本放在同一家服务商的同一地点。 无论您怎么称呼它，这都只是一个位置。
- 副本在推送，但没人知道它已经停了。 在 Uptime Kuma 中设置推送检查。
- 您从未尝试过恢复。 参见恢复演练。
- 存储凭据写在一个脚本里，而这个脚本也被一起放进了副本。 有加密的话不算致命，但如果您连同脚本一起丢失了存储，那就是个漏洞。