G够VPS

商家突然跑路：72小时数据抢救清单

没人觉得跑路会轮到自己，直到控制台打不开的那天。小够给你一份72小时数据抢救清单：前4小时确认状况抢数据，24小时内新商家开服切流量，72小时内恢复业务并启动退款流程。

我是小够。先说句扎心的话：所有觉得"这家挺稳，不会跑路"的人，和所有真的遇到跑路的人，是同一批人。跑路这事不看你多精明，只看你有没有预案。

下面这份清单，是给"已经出事了"的你。打印出来也行，收藏也行，希望你永远用不上。

0-4 小时：确认状况，抢数据

第一步：确认是不是真的出事了。 控制台打不开，先别慌：去商家的状态页、TG 频道、官方论坛看看；去 NodeSeek、V2EX、LowEndTalk 搜一下，看是不是只有你一个人遇到。有时候只是区域性故障或 DDoS，别自己吓自己。

第二步：如果 SSH 还能连，立刻抢数据。 这是黄金时间，优先级排序：

  1. 数据库：先 mysqldump 或对应工具导出，数据库丢了最难恢复
  2. 网站文件和用户上传：rsync 或 scp 拉到本地
  3. 配置文件：Nginx、Docker compose、定时任务， /etc 里关键的都打包

第三步：如果已经连不上了，立刻开工单+发邮件。 留下书面记录，这对后面的退款争议是证据。同时把"最后一次备份"找出来——你平时有备份吧？

4-24 小时：新商家开服，切流量

别在原地等奇迹。4 小时没恢复，就当它已经没了，开始重建：

  1. 选新商家：救急优先选大厂云（Vultr、DigitalOcean、Linode 这些十多年老牌，开通快、文档全），等业务稳定了再慢慢挑便宜的。
  2. 恢复数据：按"系统→数据库→文件→配置"的顺序重建，先让服务跑起来，优化以后再说。
  3. 切 DNS：把域名解析切到新 IP。这里有个教训——平时就把 DNS 的 TTL 设低一点（比如 300 秒），出事时切换才快。TTL 设了一天的，切完要等一天才全球生效。

24-72 小时：恢复业务，启动退款

业务恢复后，做三件事：

  1. 通知用户（如果有）：简单说明情况，别甩锅，给出恢复时间。
  2. 启动退款流程：如果商家还能联系，走正常退款；如果失联，收集证据（订单截图、付款记录、工单记录），走 PayPal 争议或信用卡拒付。注意时效，拖得越久越难。
  3. 复盘：这次丢了什么数据？为什么备份没 cover 到？把教训写下来。

抢数据的工具箱：平时就备好

抢数据拼的是速度，工具平时就要装好、练熟：

  • rsync：增量同步神器，rsync -avz 一把梭，大文件断点续传也不怕
  • mysqldump / pg_dump：数据库导出，出事时第一优先级就是它
  • tar 打包：配置文件、网站文件，一把打包再传，比单个文件传快得多
  • rclone：直接把数据推到对象存储，适合数据量大的情况

建议：平时就把这些工具装好，把备份脚本写好。真出事的时候，你只有"执行"的份，没有"现学"的时间。

备份方案：3-2-1 原则详解

前面提到了 3-2-1，这里展开说说：

  • 3 份数据：生产环境 1 份 + 本地备份 1 份 + 异地备份 1 份
  • 2 种介质：比如 VPS 快照 + 本地硬盘，或对象存储 + 本地 NAS
  • 1 份异地：异地是灵魂。同城的备份，挡不住机房级故障

对个人用户来说，最低配的 3-2-1 是：VPS 商家快照 1 份 + 每周 rsync 到本地电脑 1 份 + 每月推一份到对象存储。成本几乎为零，效果天差地别。

选新商家的救急标准

出事时选新商家，标准和平时不一样，要"快"字当头：

  1. 开通速度：选秒开的，大厂云一般都没问题
  2. 按小时计费：救急先按小时开，稳定了再转包月/年付，别在慌乱中做长期决策
  3. 数据中心就近：选离你用户近的机房，先恢复服务，优化以后再说
  4. 别贪便宜：救急时买特价小商家，等于刚出虎穴又入狼窝

退款维权：证据链清单

如果走到退款/争议这一步，这些证据缺一不可：

  • 订单截图（含套餐、金额、日期）
  • 付款记录（PayPal 账单、信用卡账单截图）
  • 服务中断的证明（ping 测试、状态页截图、论坛讨论）
  • 和商家沟通的记录（工单、邮件，一个都别删）
  • 损失清单（数据价值、业务损失，争议时用得上）

先走商家正常退款流程；商家失联，再走 PayPal 争议；再不行，信用卡拒付。一步一步来，别跳步——发卡行会问你"联系过商家吗"，答不上来直接驳回。

预防：平时就要做好的 5 件事

抢救清单是"出事后"的，这 5 件事是"出事前"的：

  1. 自动备份：每天凌晨自动备份数据库+网站文件，推到异地（对象存储或另一台 VPS）
  2. 配置即代码：Nginx 配置、Docker compose、部署脚本，全部用 git 管起来。重建时 git clone 就行，不用凭记忆
  3. DNS TTL 设低：A 记录 TTL 设 300 秒，平时没影响，出事时切换快
  4. 留一台备用机：便宜小鸡就行，平时当测试机，出事时当救生艇
  5. 记下关键信息：把各商家的工单地址、客服邮箱、你的订单号，记在一个文档里。出事时你慌，文档不慌

这 5 件事平时花不了多少时间，出事时每一条都能救命。

常见问题

Q：怎么判断商家是真跑路还是临时故障？ A：看三处：官网状态页、官方 TG/论坛、第三方论坛（NodeSeek、V2EX、LowEndTalk）有没有其他人讨论。超过 24 小时无任何官方回应，就按最坏情况处理。

Q：数据没备份，还有救吗？ A：如果 SSH 还能连，立刻手动抢数据；如果连不上了，只能等商家恢复。教训：备份永远是第一位的。

Q：跑路的商家还能退款吗？ A：能联系上就走正常退款；失联就收集证据走 PayPal 争议或信用卡拒付。注意时效，拖得越久越难。

心理建设：别自责，向前看

最后说点虚的，但重要。遇到跑路，很多人第一反应是自责：“我怎么这么蠢”。别这样。VPS 圈跑路是系统性风险，再精明的人都可能中招。

正确的心态是：把这次当成一次"压力测试"，测试你的备份、你的预案、你的冷静。能从容应对一次跑路，你的运维水平就上了一个台阶。交学费不可怕，可怕的是交了学费没学到东西。

事后：把"下次"变成"不会再有下次"

跑路一次，最大的收获应该是这套习惯：

  • 3-2-1 备份：3 份数据，2 种介质，1 份异地。VPS 上的数据，至少有一份在你自己手里。
  • 别把鸡蛋放一个篮子：重要业务至少两家商家，一主一备。
  • 预付费别贪多：年付一时爽，跑路火葬场。新商家先月付，关系处熟了再年付。
  • 定期演练：备份了不等于能恢复，每季度做一次恢复演练。

最后说一句：跑路防不住，但损失防得住。预案的价值，平时看不见，出事那天全是它。