G够VPS

VPS备份方案：321原则

小够讲 VPS 备份的 321 原则：3 份拷贝、2 种介质、1 份异地，附低成本落地方法和恢复演练清单，备份没测过等于没有。

我是小够，只推够用的 VPS。

备份是 VPS 玩家最后的兜底，也是最容易被忽视的一环。我见过太多悲剧：商家跑路，数据全没；自己手滑 rm -rf，删完才想起没备份；被黑了要重装，发现唯一的备份在被黑的机器上。血的教训总结成一句话：VPS 只是你数据的其中一个副本，永远不要是唯一副本。

这篇讲备份的 321 原则——不是什么高深理论，是美国国家档案馆级别的实践总结，个人用完全够用，关键是落地。

321 原则是什么

三句话：

  1. 3 份拷贝：重要数据至少保留 3 份。一份在用（你 VPS 上的原件），两份备份。
  2. 2 种介质：备份放在至少 2 种不同的存储介质上。比如一份在另一台 VPS 的硬盘，一份在对象存储 / 网盘。别把两份备份放同一台机器的两个目录——那叫复制，不叫备份。
  3. 1 份异地：至少 1 份备份放在和原件不同的地理位置。VPS 在洛杉矶，备份可以放法兰克福的机器、或者国内的网盘。机房失火、商家跑路、整站被墙，异地那份能救命。

记住一个反例：有人把网站备份放在网站的 /backup/ 目录下，机器一丢，备份跟着丢。这就是典型的"假备份"。

为什么 VPS 特别需要备份

第一，商家快照不等于备份。Vultr、DO、Linode、搬瓦工这些都提供快照功能，但快照存在商家的存储上：商家跑路，快照跟着没；账号出问题被封，快照拿不出来；快照本身也可能损坏。快照是"方便回滚"的工具，不是"数据保险柜"。正确姿势：快照 + 自己的一份异地备份，两条腿走路。

第二，VPS 是非托管的。商家不管你的数据，这是行规。硬盘坏了、母机故障，商家顶多给你重开一台，数据找不回来别指望赔偿——服务条款里都写了，数据是用户自己的责任。

第三，人为失误比黑客更常见。rm -rf / 输错一个空格、数据库 DROP 选错库、升级失败，这些比被黑的概率高得多。备份防的不只是黑客和跑路，更是防自己手滑。

第四，恢复是有时效的。网站挂了，每多一小时，损失多一分。有现成备份，半小时恢复；没备份，从头重建，三天起步。备份买的是"恢复速度"。

先回答：备份什么

不是所有东西都值得备份。VPS 上分三类：

必须备份（丢了找不回来）：

  • 网站数据：/var/www 这类目录，用户上传的图片、附件
  • 数据库：MySQL / PostgreSQL 的数据，网站的命根子
  • 配置文件：Nginx / Apache 配置、PHP 配置、防火墙规则，自己调过的参数重配一遍很费时间
  • 密钥和证书：SSH 密钥、SSL 证书、API 密钥。注意备份本身要加密，别把密钥明文扔网盘

可以备份（丢了能重建，但费时间）：

  • 系统环境：一键包、Docker compose 文件。建议把搭建过程写成脚本或文档，丢了照着重跑一遍
  • 日志：排查问题用，一般保留近期的就行，不用长期备份

不用备份：

  • 系统本身：重装 5 分钟的事，备份整个系统镜像又大又慢
  • 缓存、临时文件：本来就是一次性的

一句话：备份"数据 + 配置"，不备份"系统"。重建的思路是：新机器装好系统 → 恢复配置 → 导入数据 → 上线。

落地方法一：脚本 + 定时任务（最通用）

适合所有 Linux VPS，零成本。一个典型的备份脚本长这样：

#!/bin/bash
DATE=$(date +%Y%m%d)
BACKUP_DIR="/root/backup"

# 1. 备份网站文件
tar -czf $BACKUP_DIR/www-$DATE.tar.gz /var/www

# 2. 备份数据库
mysqldump -u root -p'你的密码' --all-databases | gzip > $BACKUP_DIR/db-$DATE.sql.gz

# 3. 备份关键配置
tar -czf $BACKUP_DIR/conf-$DATE.tar.gz /etc/nginx /etc/php

# 4. 只保留最近 7 天的本地备份，自动删旧的
find $BACKUP_DIR -name "*.gz" -mtime +7 -delete

然后 crontab -e 加一行，每天凌晨 3 点跑：

0 3 * * * /root/backup.sh >> /var/log/backup.log 2>&1

关键细节：

  • 备份脚本里的数据库密码，别用 root 的日常密码，建一个只有备份权限的专用账号。
  • 本地只留 7 天，备份完一定要传到异地（见方法二），本地备份只防"手滑删文件"这种小事故。
  • 备份日志要看，脚本报错了你不知道，等于没备份。可以加个简单的成功 / 失败通知，参考本站的监控告警自建，Uptime Kuma 也能顺带监控备份任务。

落地方法二：rclone + 对象存储 / 网盘（异地那份）

321 原则里的"异地"，最省事的方案是 rclone + 云存储。rclone 支持几十种存储：S3 兼容的对象存储、Google Drive、OneDrive、Dropbox、国内的阿里云 OSS / 腾讯云 COS 都行。

基本流程：

  1. 服务器上装 rclone，rclone config 按向导配好存储（以 S3 兼容存储为例，填 endpoint、key、secret）。
  2. 备份脚本最后加一行：rclone copy /root/backup remote:备份桶/vps-backup/，每天的备份自动同步上去。
  3. 云存储开版本控制 / 跨区域复制（如果有），防止备份文件本身被误删。

成本：个人小站的备份一般就几个 GB，对象存储一个月几毛钱，网盘甚至免费。异地备份的成本，低到没有借口不做。

注意：如果备份里有用户数据、密钥，传云之前先加密。可以用 rclone 的 crypt 功能，配一个加密 remote，传上去的是密文，云厂商也看不到明文。

落地方法三：另一台便宜 VPS 互备（进阶）

手里有两台以上 VPS 的，可以互为备份：一台洛杉矶的站，备份传到法兰克福 / 新加坡的机器上。用 rsync 增量同步，又快又省流量：

rsync -avz --delete /root/backup/ 用户名@备份机IP:/backup/主站/

--delete 让两边保持一致，旧备份自动清理。备份机买最便宜的就行——RackNerd $10.6/年的款、BuyVM $2/月的款，硬盘大、流量足，当备份机很合适。备份机本身也要备份？不用，备份机丢了，主站还在，重新买一台就行——这就是 3 份拷贝的意义。

数据库备份的特别注意事项

数据库是备份里最容易翻车的一环：

  1. 必须用工具导，别直接拷文件。MySQL 运行中直接拷 /var/lib/mysql 的文件，拷出来大概率是坏的。用 mysqldump 或 xtrabackup，PostgreSQL 用 pg_dump。
  2. 大库分开备。几十 GB 的库，--all-databases 一把梭又慢又容易失败，按库分开导，失败了也好重试。
  3. 备份完验证。gzip -t 测一下压缩包完整性，定期（比如每月）拿一份备份在测试机上恢复一遍，确认能导进去。没验证过的备份，等于没有备份，这句话值得贴在显示器上。
  4. binlog 也留一份。对业务重要的数据，MySQL 开 binlog，配合每天的全量备份，可以恢复到任意时间点。个人小站可以不搞，但要知道有这个选项。

WordPress 站的备份方案（举例）

WordPress 是国内个人建站最多的程序，单独说一下：

  • 文件：wp-content/uploads（上传的图片附件）必须备，主题和插件可以不备（能重新下载，但自己改过的主题要备）。
  • 数据库：整个库都备，文章、评论、设置全在里面。
  • 懒人方案：UpdraftPlus 这类插件，设置好定时备份到 Google Drive / S3，点几下就行。适合不想写脚本的新手。
  • 手动方案：按方法一的脚本，tar 打包 wp-content，mysqldump 导库，rclone 传异地。

恢复流程：新机器装 LNMP → 解压文件 → 导入数据库 → 改 wp-config.php 里的数据库信息 → 完事。提前在本地演练一遍，真出事不慌。

备份频率：RPO 和 RTO

两个术语，搞懂了就知道自己该多久备一次：

  • RPO（能丢多少数据）：每天备份一次，最多丢 24 小时的数据。你的业务能接受丢一天的数据吗？个人博客可以，电商订单不行。接受不了的，提高频率（每 6 小时、每小时），或者上 binlog / 实时同步。
  • RTO（多久能恢复）：从出事到恢复上线要多久。有现成备份 + 演练过的流程，半小时；没演练过，三小时起步。RTO 靠演练压下来，不是靠备份本身。

个人小站的够用配置：每天一次全量备份，保留 7 天本地 + 30 天异地，每季度演练一次恢复。这个配置的成本几乎为零，覆盖了 95% 的事故场景。

恢复演练：每年至少一次

备份最大的坑，不是没做，是做了但恢复不了：压缩包坏了、数据库版本对不上、少备了某个配置文件、备份脚本半年前就报错了。演练方法：

  1. 开一台按小时计费的临时机器（Vultr 按小时计费很适合干这个，用完删掉，几毛钱）。
  2. 按你的恢复文档，从零重建：装系统 → 恢复配置 → 导入数据。
  3. 检查网站能不能打开、功能正不正常。
  4. 把演练中发现的问题（少了哪个文件、哪个步骤卡壳）记下来，更新备份脚本和文档。
  5. 删掉临时机器。

演练一次 1-2 小时，一年一次，换来的是"真出事了我能恢复"的底气。这钱（时间）花得值。

不同场景的备份策略

个人博客 / 小站：每天一次全量，本地 7 天 + 异地 30 天。脚本 + rclone 全自动，每季度演练一次。这是本文的默认配置，照抄就行。

电商 / 有订单的业务：RPO 要求高，每天一次不够。方案：每天全量 + 每小时增量（数据库 binlog 或定时 dump），异地实时同步。恢复演练每季度一次，RTO 目标 1 小时内。这种业务建议再看本站的电商场景选购思路，机器本身也要选更稳的。

学习折腾机：备份配置文件和脚本就行（dotfiles、docker-compose 文件扔 GitHub 私有仓），数据不重要，丢了重装。别在这上面花太多时间，够用就行。

多台机器：写一份统一的备份脚本，所有机器用同一套，备份集中传到一台备份机 + 一份云存储。机器多了之后，备份策略也要"基础设施化"，别每台搞一套，维护不过来。

常见误区

误区一：“我有快照，不用备份”。快照是商家的，备份是自己的。商家跑路、账号被封，快照拿不出来。快照 + 异地备份，两条腿走路。

误区二：“备份=把文件复制一份放旁边”。放同一台机器的另一个目录，不叫备份，叫复制。机器一丢，全没。至少要异地，这是 321 里最重要的那个"1"。

误区三：“备份了就万事大吉”。备份要验证、要演练。没恢复过的备份，关键时刻掉链子的概率极高。

误区四：“等数据重要了再备份”。数据重要的时候，往往已经来不及了。备份要从第一天开始，养成习惯。反正成本几乎为零，早做早安心。

误区五：“备份传到网盘就安全了”。网盘账号被盗、分享链接泄露，备份里的密钥和用户数据就裸奔了。含敏感信息的备份，加密后再上传，rclone crypt 配一次，终身受益。

一句话总结

321 原则：3 份拷贝、2 种介质、1 份异地。落地：每天脚本自动备 → rclone 传异地 → 每季度演练恢复。成本几乎为零，覆盖 95% 的事故。备份不是技术问题，是习惯问题，从今天开始。

常见问题

Q：个人小博客，真的需要搞这么复杂吗？

A：321 是原则，落地可以简化。最低配：每天自动备份（脚本 10 分钟写完）+ 传到网盘 / 对象存储。5 分钟配置，之后全自动。等你的站真有流量了，再加演练和更细的策略。

Q：备份保留多久合适？

A：本地 7 天（防手滑），异地 30 天（防"一周后才发现数据坏了"）。想更保险，异地每月留一份，保留 6-12 个月。存储成本很低，别在这上面省。

Q：数据库密码写在备份脚本里，安全吗？

A：脚本权限设 600（只有 root 能读），再给备份建专用数据库账号（只有 SELECT 和 LOCK TABLES 权限）。更好的做法是用 ~/.my.cnf 存密码，脚本里不出现明文。

Q：备份传到国内网盘，速度慢怎么办？

A：备份文件先压缩（gzip / zstd），个人小站一般就几十 MB，传上去很快。量大的话，rclone 支持增量同步和多线程（--transfers 8），或者直接用海外的 S3 兼容存储，不走国内网盘。

Q：商家说提供"自动备份"服务，要买吗？

A：可以买，但别只依赖它。商家的自动备份本质是"托管的快照"，方便，但还是在商家手里。把它当作 321 里的其中一份，再自己做一份异地备份，就齐活了。