G够VPS

鸡蛋不放一个篮子：重要业务的双商家备份策略

重要业务只放在一家VPS商家，等于把命运交给别人。小够讲透双商家备份策略：主备架构怎么搭、数据怎么同步、DNS怎么切、备用机选多便宜的，以及多久演练一次。

我是小够。今天聊一个很多人"知道但没做"的事：重要业务，别只放在一家 VPS 商家。

道理都懂：商家宕机、跑路、IP 被封，任何一家出问题，你的业务就跟着躺。但真到掏钱买第二台机器的时候，很多人就犹豫了——“有必要吗？““太贵了吧？“这篇就把双商家策略讲透，让你知道它没你想的那么贵，也没你想的那么复杂。

为什么一定要双商家

先算一笔账：你的业务如果宕机一天，损失多少？对个人博客来说，可能只是少几个访客；但对接单的外贸站、跑业务的 API 来说，一天宕机可能是实打实的订单损失。

而一台备用小鸡，一个月也就几美元。用"几美元/月"的成本，对冲"宕机一天"的损失，这笔账怎么算都划算。双商家不是奢侈，是保险。

注意是"双商家”，不是"同一商家的两台机器”。同一商家机房故障，两台一起躺，等于没备。

架构一：主备模式（推荐大多数人）

最简单的双商家架构：

  • 主机：跑实际业务，配置按需求来
  • 备机：低配小鸡，平时只同步数据，不对外服务

数据同步怎么做：

  1. 文件同步：rsync 定时任务，每天凌晨把网站文件同步到备机
  2. 数据库同步：MySQL/MariaDB 做主从复制，或者每天 mysqldump 传过去
  3. 配置同步：Nginx 配置、Docker compose 文件，用 git 管起来，两台机器都能拉

备机平时处于"热备"状态：系统装好、服务配好、数据同步着，只是 DNS 没指向它。主机一挂，改 DNS 解析，几分钟内恢复。

架构二：双活模式（业务量大的再考虑）

两台机器同时对外服务，流量按比例分。这需要负载均衡和数据实时同步，复杂度高一个量级。对个人和小团队来说，主备模式完全够用，别一上来就挑战双活。

DNS 切换：平时就要准备好

双商家策略里，DNS 是切换开关，平时就要准备：

  1. TTL 设低：把 A 记录的 TTL 设为 300 秒（5 分钟）。平时 TTL 长没关系，但至少要知道在哪改、怎么改。
  2. 用靠谱的 DNS 服务商：Cloudflare 免费版就够，切换解析秒级生效（配合低 TTL）。
  3. 把切换步骤写下来：真出事的时候，人是慌的。对着 checklist 操作，比临场发挥靠谱十倍。

备机选多便宜的

这是大家最关心的：备机不需要和主机同配置。备机的任务是"顶住”，不是"跑满”：

  • 主机 2 核 4G，备机 1 核 1G 完全够用
  • 备机选便宜大流量的商家就行，比如年付十美元档的小鸡
  • 备机平时不跑业务，超售鸡都能胜任——反正只是 standby

算下来，备机一年也就几十块人民币，比一次宕机的损失便宜多了。

演练：不演练的备份等于没有备份

双商家策略最大的坑，是"搭了但没演练过"。真出事才发现：备机的数据是三个月前的、DNS 不会切、配置对不上。

我的建议：每季度演练一次。流程很简单：

  1. 把备机的数据同步到最新
  2. 改 hosts 文件，把域名指向备机 IP，验证业务正常
  3. 恢复 DNS，记录演练中发现的问题

一次演练半小时，换来的是真出事时的不慌。

数据同步方案对比：选适合你的

方案优点缺点适合
rsync 定时同步简单，半小时搭好非实时，有延迟个人博客、小站
数据库主从复制实时，数据不丢配置稍复杂有数据库业务
对象存储中转可靠，不怕单点有额外成本文件多的站
容器镜像同步环境一致，恢复快要学 Docker用容器的团队

对大多数人，我推荐"rsync + 每天数据库 dump"的组合：简单、可靠、成本为零。别一上来就搞主从复制，复杂度是故障的温床。

一个实用的同步脚本思路：每天凌晨 3 点，rsync 同步网站目录，mysqldump 导出数据库并压缩，两个都推到备机，保留最近 7 天。写成 shell 脚本加到 cron，一劳永逸。

DNS 服务商选择

DNS 切换的速度，取决于你的 DNS 服务商：

  • Cloudflare（免费版）：切换解析全球生效快，有 API 可以写自动化脚本，个人用户的首选
  • 域名注册商自带 DNS：能用，但生效慢、功能少，应急时可能掉链子
  • 国内 DNS 服务商：如果用户主要在国内，解析速度有优势，但切记提前备案相关要求

不管用哪家，记住两点：TTL 设低（300 秒），切换步骤提前写好。真出事时，你只有"执行"没有"研究"的时间。

故障切换标准流程（SOP）

把切换流程写成 SOP，贴在你的运维文档里：

  1. 确认故障（5 分钟）：ping、SSH、状态页三处确认，不是误报再动手
  2. 同步最新数据（10 分钟）：手动触发一次 rsync + 数据库 dump，确保备机数据最新
  3. 切换 DNS（5 分钟）：把 A 记录指向备机 IP，TTL 已经是 300 秒的话，几分钟生效
  4. 验证业务（10 分钟）：用手机流量（非 WiFi）访问网站，确认业务正常
  5. 通知相关方：如果有用户，发个简短通知

全程 30 分钟。平时演练过，真出事就是走流程，不慌。

演练手册：每季度一次

演练不用影响线上，用"影子演练"法：

  1. 备机数据同步到最新（和平时一样）
  2. 改自己电脑的 hosts 文件，把域名指向备机 IP
  3. 在自己电脑上完整走一遍业务流程：打开网站、登录后台、下一单
  4. 记录发现的问题：数据是不是最新的？配置有没有缺？定时任务跑了没？
  5. 恢复 hosts，写演练小结

影子演练只影响你自己的电脑，线上用户无感知。建议每季度一次，每次半小时。

成本再优化：备机不一定闲置

觉得备机"闲置浪费"，可以让它干活：

  • 监控机：跑 Uptime Kuma，监控主机的状态——主机挂了，它第一个知道
  • 测试机：新功能先在备机上测，测完再上主机
  • 跳板机：当 SSH 跳板，顺带隐藏主机真实 IP

一物多用，备机就不"闲"了。这几美元花得更值。

成本账

项目配置年成本估算
主机按业务需求该花就花
备机1 核 1G 小鸡年付十美元档
DNSCloudflare 免费版0
总计—一年几十块人民币

单商家多机房，算不算双商家？

不算，或者说，只算半个。同一商家的不同机房，能防"单机房故障"，但防不住：

  • 商家整体跑路
  • 商家账号被封（比如支付争议导致账号冻结）
  • 商家全网故障

真正的双商家，是"不同公司、不同账单、不同客服体系"。退一步说，如果预算只够一家，至少做到"同商家双机房+异地备份"，比单机房强得多。但别骗自己说这就是双商家了。

数据库同步实操：从 dump 开始

对大多数个人用户，数据库同步不用上复杂方案：

# 每天凌晨 3 点，导出并压缩
mysqldump -u 用户 -p'密码' 数据库名 | gzip > /backup/db-$(date +%F).sql.gz
# 传到备机
rsync -avz /backup/ 备机IP:/backup/
# 只留最近 7 天
find /backup -name "*.sql.gz" -mtime +7 -delete

三行命令加到 cron，数据库备份就自动化了。恢复时反向操作就行。记住：备份的价值在于"能恢复"，每季度手动恢复一次验证，别等到真出事才发现备份文件是坏的。

演练记录表

每次演练，把结果记下来：

日期演练内容发现的问题是否解决
备机数据恢复验证
hosts 切换业务验证
DNS 切换流程走一遍

演练不是走过场，发现问题才是目的。连续两次演练零问题，说明你的架构真的稳。

反方观点：什么时候可以只用单商家

说实话，不是所有业务都需要双商家。这几种情况，单商家+好备份就够了：

  1. 纯学习/测试环境：丢了重建就行，不值得为备机花钱
  2. 静态博客：源文件在本地 git 里，换个商家半小时重建，备机的意义不大
  3. 预算真的卡死：学生党一台小鸡都不容易，那就把备份做到极致——异地备份+配置即代码，恢复速度就是你的"备机"

双商家是"重要业务"的标配，不是所有场景的标配。别为了架构而架构，成本和收益要自己权衡。

备机选型：三档预算

预算配置适合
年付十美元档1 核 1G 小鸡个人博客、小业务的备机
月付 5 美元档1 核 2G有一定流量业务的备机
按小时大厂云按需开平时不开，出事才开，极致省钱

第三档最有意思：平时备机根本不存在，出事时按小时开一台，数据从异地备份恢复。虽然恢复慢一点（要重建环境），但成本几乎为零。适合预算卡得死、但又有备份习惯的人。

监控告警联动：让备机"自动"顶上

进阶玩法：用监控实现半自动切换。

  1. 备机上跑 Uptime Kuma，监控主机的 HTTP/端口
  2. 主机失联超过设定阈值（比如 5 分钟），发告警到你的手机/TG
  3. 收到告警，手动执行切换 SOP（全自动切换风险高，不建议个人用户做）

监控+告警+手动切换，是个人用户能做到的最优解。全自动故障转移是好看不好用，复杂度一上来，备机本身就成了故障点。

小够的建议

  • 个人博客：备机可以简单点，定期备份+随时能重建就行
  • 接单/业务站：主备架构+季度演练，必须做
  • 别把备机也放在同一家：双商家的"双"字是灵魂

常见问题

Q：备机长期闲置，是不是浪费钱？ A：备机可以一物多用：平时跑监控、跑测试、当前端跳板机。把它当成你的"第二台生产力机器"，就不浪费了。

Q：数据同步用 rsync 还是主从复制？ A：个人博客、小业务，rsync+每天 dump 数据库完全够用。数据量大了、实时性要求高了，再上主从复制。别过度设计。

Q：DNS 切换要多久生效？ A：TTL 300 秒的情况下，大部分地区几分钟内生效，全球完全生效可能要十几分钟到一小时。平时把 TTL 设低，是出事时最快的"保险"。

Q：两家商家怎么选？ A：一家选你信任的主力（可以是大厂云），另一家选便宜小鸡。关键是"不同商家"，最好连机房地区都错开。

Q：演练会不会影响线上业务？ A：用改 hosts 的方式演练，只影响你自己的电脑，不影响线上用户。放心演练，大胆验证。

Q：备机和主机配置差太多，切换后撑得住吗？ A：撑得住"顶一会儿"，撑不住"长期跑"。备机的任务是争取时间——给你几小时到几天，去修主机或找新商家。别指望备机长期扛，它只是个缓冲。

Q：数据库主从复制难吗？ A：MySQL/MariaDB 的主从配置，跟着官方文档走，半天能搭好。但对个人用户，我更推荐"每天 dump+rsync"：简单、可靠、够用。复杂度是故障的温床，这话再说一遍。

Q：备机平时完全闲置，感觉很浪费？ A：那就让它干活：跑监控、当测试机、做跳板机，一物多用。实在不想折腾，就把它当成"保险费"——保险的作用就是平时用不上，出事时救命。每年几十块买一份安心，不贵。

Q：小团队只有两个人，搞得动双商家吗？ A：搞得动。主备+rsync+低TTL这套，一个下午就能搭完。复杂度是按需加的，一开始别贪多，先把"能切换"跑通，再慢慢优化。