【备份系列 03】VPS 数据备份实战：快照、rsync、Restic 与异地容灾怎么搭 2026

延伸阅读

更多相关攻略推荐：【知识库自托管 02】2026 实测：VPS 自托管 Anythin、【知识库自托管 03】2026 实测：搬瓦工/RackNerd 上自、如何给 VPS 厂商做"信用评估"：跑路、超售与售后风险排查手册、【知识库自托管 01】2026 企业/个人私有文档 RAG 问答选型、2026 决策指南：本地模型 vs 云 API 成本对比——你的 V。

一、为什么 VPS 用户必须自己管备份

在共享主机上，服务商通常会帮你做备份甚至代你恢复；但一旦你上了 VPS，拿到 root 权限，备份的责任就完全落在自己肩上。VPS 给你足够的控制权，也给了你足够快把一切搞砸的能力。数据丢失几乎不是"会不会发生"的问题，而是"什么时候发生"的问题：误删目录、改错配置、磁盘故障、一次失败的升级、被入侵、甚至商家跑路，任何一条都可能让你几个月的工作归零。

我们见过太多真实案例：有人用 rm -rf 删错了路径，有人在一次升级后 Nginx 起不来，也有人在 ColoCrossing 或 RackNerd 上跑了一年业务却从没做过任何备份。等到真正需要恢复时，才发现什么都没有。这篇指南不灌鸡汤，只讲可落地的方案：自动快照、rsync 异地同步、Restic 加密增量备份到对象存储，以及最容易被忽略的恢复演练。

二、先记住 3-2-1 备份法则

这是全球运维圈公认的底线，几句话就能说清：

• 保留 3 份数据副本（生产数据 + 两份备份）；
• 存放在 2 种不同介质上（比如本地磁盘 + 对象存储）；
• 其中 1 份必须在异地（不同机房、不同商家、不同账户）。

面对勒索软件，很多人进一步扩展为 3-2-1-1-0：多加一份离线/不可变副本，以及校验零错误。对大多数个人和小型站点来说，先把基础的三份做齐就足够了。下面三层结构正好对应这个法则：商家快照是第一层快速恢复，rsync/Restic 做带版本的本地或近线备份，对象存储做异地那份。

三、备份的三种形态，别混为一谈

很多人把"快照"和"备份"当成同义词，这是灾难的开始。它们解决的是不同问题。

一个诚实的结论：快照不等于异地备份。快照和你的 VPS 躺在同一个商家的同一个账户里，如果商家账户被盗、被勒索，或者干脆跑路，快照也会一起没。快照的价值在于"刚才手滑删错，三分钟滚回来"，而不是"商家没了我的数据还在"。

四、第一层：商家快照与自动备份政策对比

针对本文面向的四家商家，我们整理了一份真实政策对比（具体以商家当下页面为准）：

从这张表能看出一个现实：便宜商家在快照上各有取舍。RackNerd 连原生快照都没有，意味着你从第一天起就该把 rsync/Restic 异地备份安排上；CloudCone 的自动备份按服务器月费 30% 收费，对低价套餐很划算；Contabo 给 1 个免费快照但仅此一个；ColoCrossing 的备份附加虽然便宜，但本质还是同商家的副本。再次强调：这些都不算异地。

五、第二层：rsync 异地同步

rsync 是 Linux 下最经典的文件同步工具，只传变化的块，适合把网站目录、配置文件增量搬到另一台 VPS。先在两台机器之间配好 SSH 密钥，让 cron 能无人值守运行：

ssh-keygen -t ed25519 -f /root/.ssh/backup_key -N ""
ssh-copy-id -i /root/.ssh/backup_key.pub backup@backup-host.example.com

最简单的同步命令：

rsync -avz --delete /var/www/html/ backup@backup-host.example.com:/backups/www/ \
  --exclude cache/ --exclude tmp/

这里 --delete 会让目标端镜像源端的删除。这既是 rsync 的方便之处，也是它最大的坑：源端一旦误删或文件损坏，破坏会忠实地同步过去。所以它更适合"服务器复制、迁移、暂存同步"，而不是需要时间点恢复的严格备份。

如果你想要带历史版本的 rsync 备份，可以用 --link-dest 做硬链接快照，每天一份、共用未变化的文件块，既省空间又能回滚到具体某天：

rsync -aAXH --delete \
  --link-dest="$DEST_ROOT/latest" \
  -e "ssh -i /root/.ssh/backup_key" \
  /var/www /etc /home \
  backup@backup-host.example.com:$DEST_ROOT/$DATE

再用 cron 每天凌晨 3:15 跑：

15 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

诚实提醒：rsync 本身不加密、不版本化、不做去重。敏感数据建议在管道里套一层 gpg，或者干脆用下面要讲的 Restic。

六、第三层：Restic 加密增量备份（详见系列第 1 篇）

Restic 是这一层最值得学的工具：默认就做对三件事——AES-256 客户端加密、内容去重、块级增量，原生支持 S3、Backblaze B2、Cloudflare R2。它和 rsync 定位不同：rsync 是"镜像"，Restic 是"带版本、能加密去重的历史仓库"。完整的安装、初始化、备份/恢复命令与自动化脚本，我在本系列第 1 篇《restic + rclone 加密去重备份实战》里逐行写过了，这里不重复贴命令，只给结论：第一次备份 50GB 约几十分钟，之后每天增量 2–5 分钟；50GB 仓库放 B2 约 $0.30/月；口令丢了仓库永远打不开，务必离线保存。

对象存储本身不贵，2026 年参考价（以官方页面为准）：Backblaze B2 约 $0.006/GB·月（出流量 $0.01/GB，恢复常不花钱）；Cloudflare R2 $0.015/GB·月（出口永远免费）；Contabo 对象存储约 €0.010/GB·月（欧洲节点、S3 兼容）；AWS S3 $0.023/GB·月（出流量 $0.09/GB，适合 AWS 生态）。预算紧张的用户，R2 的零出口费与 Contabo 对象存储的欧洲节点最值得优先考虑。

七、数据库备份的两个要点

• 先 dump 再备份：不要直接对运行中的数据库文件做快照或 rsync，那只是"崩溃一致性"副本，恢复后可能损坏。正确做法是先 mysqldump 或 pg_dump 导出成平文件，再让 restic 去备份这个文件。
• 用 --single-transaction：对 InnoDB 这类事务型引擎加这个参数，可以在不锁表的情况下拿到一致快照。

mysqldump --single-transaction --quick mydb | gzip > /tmp/mydb.sql.gz
pg_dump -U postgres mydb | gzip > /tmp/mydb.sql.gz

八、最容易被跳过的一步：恢复演练

没演练过的备份等于没备份。很多人在真正出事时才发现备份文件是空的、脚本写出了空文件、或者恢复根本不完整。建议至少每月做一次：

• rsync 用 --dry-run 确认远端目录树符合预期；
• Restic 在临时机跑一次 restic restore latest --target /tmp/restore-test，挑几个文件和生产环境 diff；
• 对象存储副本用 rclone check 做校验和比对，而不只是看文件在不在；
• 记录你的 RTO（恢复需要多久）和 RPO（能接受丢多少数据），这俩数字决定你的备份频率和手段。

把恢复步骤写成 runbook，这样哪怕搭系统的人不在，别人也能照着恢复。千万别在正式机上演练恢复。

九、一个可落地的最小组合

预算紧张也能做齐三层：

• 开启商家自动备份或快照作为第一层（CloudCone 30% 月费、Contabo 免费快照都很好用）；
• 用一台更便宜的 VPS（例如 ColoCrossing 年付十来美元）做 rsync 异地副本，作为第二层；
• 再加一个 Restic 仓库推到 Cloudflare R2 或 Backblaze B2，作为真正异地的第三层。

这样每月额外成本可能只有一两美元，却扛得住误删、磁盘坏、机房故障、甚至商家跑路。

十、几个必须说清楚的缺点

• 快照不是异地：同商家同账户，跑路即全失。文章里反复强调不是废话。
• rsync 会放大错误：误删和损坏会被同步过去，别把它当唯一备份。
• Restic 口令丢失不可逆：设计上没有任何找回机制，务必离线保存。
• 同账户备份防不住勒索：如果攻击者拿到你的 VPS 权限，也可能顺手删掉同账户的快照，考虑不可变/离线副本。
• 静默失败最危险：cron 失败没人知道，等于没备份。加 flock 防重叠，加 MAILTO 或 Healthchecks 心跳做告警。

十一、结语

备份这件事没有捷径，但也没有想象中复杂。把快照、rsync、Restic 三层搭起来，每月花一两美元，你就能安心睡觉，而不是在某天早上发现一切都没了。本文提到的商家快照政策、自动备份价格、对象存储资费都以商家当前页面为准，促销和计费规则会变动，下单前请再核对一次官方说明。具体促销以商家页面为准。