2024 年 3 月 12 日，星期二
今天下午三点，QQ 弹了一条消息。一个客户发来的，就一句话：”网站打不开了。”
我打开浏览器，输入域名——白屏。不是 404，不是 500，是纯白屏。F12 看了下，数据库连接失败。
我心想，大概率是服务器临时抽风，重启一下就好了。登录宝塔面板，点进数据库管理——MySQL 服务状态显示”已停止”。点启动，报错：Table 'wp_posts' doesn't exist。不熟悉宝塔面板的话，可以先看这篇宝塔面板部署网站完整教程，里面有数据库管理的基础操作。
wp_posts 表不存在。
我盯着屏幕愣了大概十秒钟。wp_posts 是 WordPress 的核心表，里面存着所有文章、页面、草稿。这个表不存在，意味着整个网站的文章数据消失了。
赶紧查错误日志。日志里有一行触目惊心：
[Warning] InnoDB: Table 'wordpress/wp_posts' is corrupted. Dropping...数据库自己把 wp_posts 表删了。原因是什么暂时不清楚——可能是磁盘写入错误，可能是 MySQL 崩溃，可能是服务器商那边做了什么操作。但不管原因是什么，结果是一样的：文章数据没了。
我深吸一口气，打开备份目录。
空的。
这个网站我接手的时候，客户说”备份我自己会做”。我相信了。他自己确实”会做”——他装了一个备份插件，但从来没配过自动任务。插件装了就放在那，像一个灭火器，挂在墙上，但从来没检查过里面有没有干粉。
接下来两个小时，我做了这些事：
- 联系服务器商，问能不能从磁盘快照恢复。回复：没有快照。
- 检查 WordPress 自带的文章修订记录（revisions）。还在，但只保留了每篇文章的最近几个版本，而且全是 HTML 片段，没有完整的文章数据。
- 翻本地的聊天记录，看看有没有发给客户审稿时留下的 Word 文档。找到两篇，还有 30 篇没有。
晚上八点，我坐在电脑前，确认了一个事实：这个网站 32 篇文章，只剩两篇有备份。
2024 年 3 月 13 日，星期三
今天早上醒来第一件事，不是刷牙，是打开电脑检查自己网站的备份。
我有备份，我知道。UpdraftPlus 每周自动备份到百度网盘。但自从装好之后，我从来没验证过这些备份能不能恢复。
验证一台车的安全气囊能不能弹出来，你只能撞一次。但验证一份备份能不能恢复，你只需要在本地搭一个测试环境，把备份导进去试试。我从来没试过。
打开百度网盘，找到最近的一个备份文件，下载下来。解压，里面是五个 zip 包：插件、主题、uploads、数据库、其他文件。数据库那个包只有 3MB，对于一个几十篇文章的网站来说，大小正常。
在本地用 XAMPP 搭了一个临时 WordPress，把备份文件按目录还原，导入数据库——报错了。
#1064 - You have an error in your SQL syntax
数据库备份文件损坏了。不是全部损坏，是中间有一段 SQL 语句不完整，导致后续所有表都无法导入。损坏的部分，恰好是 wp_posts 表。
我坐在那，心情很复杂。一方面，这不是客户网站那种”完全没有备份”的绝望。另一方面，我有备份，但备份是坏的——这种感觉比完全没有备份更难受。你明明做了该做的事，但结果是一样的。
花了两个小时，用文本编辑器打开那个 3MB 的 SQL 文件，手动修复了损坏的部分。最后导入了大概 80% 的数据。少了三篇文章，但至少不是全军覆没。
这件事让我意识到一个之前没想过的概念：备份不是做了就行，备份是可恢复的才行。
2024 年 3 月 14 日，星期四
今天把客户网站重建了。32 篇文章，凭记忆和我这边留的草稿，恢复了大概 20 篇。剩下的 12 篇，真的没了。有些文章我自己也记不清写了什么——那些半夜灵感来了随手写的段落，那些反复修改了好几遍的措辞，那些找了一下午数据的表格，全没了。
客户没怪我。他说他自己也有责任。但我知道，如果我在接手的当天就帮他配好自动备份，这件事根本不会发生。
下午，我把自己的备份流程重新梳理了一遍。之前是”装好就不管了”，现在变成了一个有明确步骤的流程。备份是最后一道防线，但防线前面还有攻击者——如果你连网站被黑了怎么排查都不知道，有备份也不够。之前写过一篇网站被黑后从排查到修复的完整流程，建议和这篇一起看，安全防护 + 备份恢复，两块拼起来才是完整的。
第一，备份频率根据更新频率来。 不是”每周备份一次”就适合所有人。如果你每天都发文章，每天备份一次。如果一周发一篇，每周备份一次。如果你一个月没更新了，备份频率可以降低，但数据库至少每周备份一次。文章数据比什么都值钱——服务器配置丢了可以重建，主题丢了可以重装，文章丢了就真的丢了。
第二，备份文件存在不同的地方。 以前我只存在百度网盘。现在加了两个位置：一份在服务器本地（宝塔面板自带的备份功能），一份在阿里云 OSS（对象存储，很便宜，几块钱一个月）。三份备份，三个不同的地方。服务器炸了、百度网盘挂了、阿里云出问题了——三个同时炸的概率，比我中彩票还低。
第三，每隔一段时间还原一次备份。 不是每次都要，但至少三个月一次。在本地搭一个测试环境（XAMPP 十分钟搞定），把最新的备份导进去，打开网站看看文章在不在、图片在不在、页面能不能正常打开。花半小时，但能避免”备份是坏的”这种噩梦。
第四，养成手动备份习惯。 自动备份是底线，但在做任何大操作之前——比如升级 WordPress 版本、换主题、改数据库结构——手动备份一次。这个习惯花 30 秒，但能让你在操作翻车的时候有后悔药。
2024 年 3 月 15 日，星期五
今天客户网站重建完了。百度重新收录了恢复的 20 篇文章，排名掉了不少，但至少不是从零开始。
晚上，我把我所有网站的备份配置都检查了一遍。发现有一个网站的自动备份任务，上次执行是两个月前。原因是 UpdraftPlus 的定时任务被 WordPress 的 cron 机制跳过了（WordPress 的 cron 不是真正的服务器定时任务，需要有人访问网站才会触发）。如果网站流量低，访问量不够，cron 可能好几天不跑一次，备份也就跟着停了。
修了这个问题，换成了服务器级别的 cron job，不依赖 WordPress 的访问触发。
三天，两台服务器，一个数据灾难，一个差点发生的灾难。侥幸心理在这三天里被彻底打碎了。
好了，这篇日记到这里就结束了。写这篇文章的时候，距离那三天已经过去了一年多。我现在回头看，觉得那三天其实是一个很贵的教训——代价是 12 篇再也找不回来的文章，和一个差点坏掉的备份。
如果你读到这里，别等数据丢了再行动。三个动作，现在就能做：
第一，打开你的网站后台，看看有没有装备份插件。 没装的话，装 UpdraftPlus，免费版够用。装完立刻手动备份一次，然后设置每周自动备份，存到远程——百度网盘、阿里云 OSS、Google Drive，哪个都行，只要不是服务器本地。
第二，下载一份最近的备份，在本地还原一次。 不用完整还原，只要能确认数据库能导入、文章能显示就行。花半小时，买一个安心。
第三，记下今天日期。 三个月后，再还原一次。
来自 wujianzhan.com，一个分享建站与 SEO 实战的博客。
