前段时间网站经历了一次严重的文件损坏，庆幸数据库还有留存，但研究修复的方法足足用了 4 个晚上，我想梳理一下这次并不容易的解决过程，如果是只想看 wdcp + wordpress 环境下如何还原 MySQL 数据库的朋友，可以直接跳到最后一节。
怎么就不长点心呢
去年流行个说法，说：黑百度现在是一种政治正确。顾名思义，政治的正确。过去两年间，B 的身位逐渐被 AT 拉开的态势十分明显，我们也的确看到了 AT 在各个领域疯狂扩张，频频涉足新产品新服务，接地气的商业模式和使用体验背后往往都有 AT 的身影。反观百度，它的存在感就矮了不止一头。好不容易亮个相，还和莆田系医疗一起被千夫所指。可能正因如此，才有江湖传言：当谷歌用人工智能击败了人类围棋王者，百度派 AI 去送了外卖。
对于百度，我以前自觉没太多资格说人家，毕竟吃人嘴软拿人手短，有骨气可以不用百度搜索医院，不往百度网盘存漂亮大姐姐，而且建站半年多来，极客飞船用的百度 BCC 云服务器一直没出过太大问题。
所以，那些听起来即鄙视又惋惜的调侃，我一向没太计较，医疗的事，坏掉的部件就要修就该换。而且在我看来，一个拥有深厚技术实力，为互联网做了那么多革新和推动，又把业务开拓重点放在未来关键领域的巨头，其颓势可能只是暂时的。
这是中国的企业，民族技术的骄傲，当然爱之深恨之切，还得感同身受。
纵使竞价审查宽松、售卖贴吧吧主、限制云盘网速，但就像你抽烟、酗酒、嗑药，仍然相信，自己是个好女孩儿一样，
个锤子。
什么仇什么怨？
忘了具体是哪一天，我手滑上传并覆盖了把一份错误的 style.css 文件，结果使网站布局被全部打乱。经查找，这份文件的正确版本可以通过前一天生成的 BCC 服务器快照找回，这是当时有且唯一的途径。在确定了一天以来，网站没有产生新的文章、评论和留言后，我决定回滚这份快照内容。
但是回滚后，我发现大量的 PHP 文件内容变成了 NULLNULLNULLNULL，用 wdCP 自带的文件管理工具查看也会提示“文件损坏”；尝试链接网站首页，内容空白。
我的第一个反应是检查源站是否有问题？
但这个可能很快被排除了，因为回溯快照生成前，到执行回滚的这一天，网站是正常运行的，我甚至还编辑并保存过一段新文字，所以问题只能是出现在 BCC 云服务器的快照备份上。
回想起有次处理百度云观测提示的端口风险，修复后却近半月不更新信息，导致网站长期处于安全项超低评分的经历，
我的脑海浮现出了三个字——大新闻。
后来感觉不是很精炼，三个字就变成了两个字——大坑。
以及还有一句必须要讲的—
Plan A
文章是作者的心血，我也希望梳理问题的过程是理性的，所以多余的情绪就让它就此打住。
作为一个主张自己动手，丰衣足食，出了问题就想方案积极解决的好站长。我找来了 WordPress 和 网站主题的源文件，对内容变成 NULLNULLNULL 的问题 PHP 文件进行了重新替换和上传。
然后重启相关服务并访问网站，提示「建立数据库连接时出错」，这是一个站长们非常熟悉的 MySQL 报错，通常表现的是：网站主页能连接，后台不能连接；或者主页和后台都不能连接。
此时的情况比较诡异—— WordPress 的后台可以正常登录、操作和保存，但主页不行，于是，
查看 mysqld 和 httpd 进程，运行中；
尝试 CentOS 登录 MySQL，可以连接；
重启 mysqld 和 apache 再试，问题依旧；
索性重启整个服务器，发现 CentOS 报错了：
*** An error occured during the file system check.
尝试使用 fsck 命令修复后，重启服务器仍然有大概率报错。
Plan A，卒。
Plan B
进行到这里也基本确定了跟 WordPress 没有多大关系，极有可能是因为这份用来回滚快照备份遭到了损坏，或者生成的过程中就出了问题。
优秀的 IT 人都是要善于分析和勇于尝试的嘛，一点小问题难不倒我们的。
既然是 1 天前的快照挂了，那 3 天前的快照应该还能工作。虽然 style.css 需要返工，但「回滚+返工样式表」的时间成本总比「回滚+检查 MySQL」或者「提交工单+等待工程师答复」来得少，而且至少能让网站再次运转起来。
出于这样的考虑，我继续确认 3 天来的网站状态：没有新文章、没有新评论、没有新留言（这网站是有多人迹罕至啊
）……最后，回滚。
回滚完成，PHP 文件还是 NULLNULLNULLNULLNULL ……
Plan B，卒。
Plan C
我想我需要一些来自运维工程师的专业支持了，于是提交了工单，写清楚问题起因、概述、发生时间、实例 ID、服务器环境和网站环境、详细表现，并上传了 CentOS 的报错截图。
遗憾的是，百度云工程师没能告诉我快照和 CentOS 的问题缘由，事实上只过问过一句“能不能单独连接数据库，MySQL 服务有没有正常启动”，之后的两天再无音讯。
难倒是因为我用的 24K 最低配纯屌丝服务器吗？可我是糯米钻石会员呀。
第三天，工程师回话了，问我还有没有在用 BCC 云服务器？
……
我顶雷个肺哦。
Plan C，卒。
Plan D —— 搬家！
骂了无数次百度扑街后，虽然继续寻找着可用的备份文件，小心机已经在盘算换服务器的事了。
而且修复工作到了这一步，我也不得不反思网站建设这么久以来，那些长久存在的问题，诸如：悬而未解的 MySQL 优化、UI 老土早就看不顺眼的 wdcp、过低的 PHP、GCC 版本对性能的影响大小等。
于是，我决定：网站搬家并且 全面升级 CentOS、PHP、MySQL。
这不是个随便的工作，决定迁移后的首要任务就是，归集好一切需要记录、备份、还原的数据和文件。
我总结了两点小建议，如果你和我的情况一样或相似：
- 一定要记录好 MySQL、Apache、Ngnix 的配置、Wordpress 后台的登录账号、那些手动修改过的文件权限；
- 尽可能下载多个相近日期的可用备份，减少风险；
七七八八的东西归集齐后，按照著名哲学家——沃德天·维森莫·拉莫帅，曾经说过的话：开整！
从 wdcp 恢复 MySQL 数据库
这里是还原 WordPress 和数据库的过程记录，注：尤其适合之前使用 wdcp 迁移后依旧使用 wdcp 的朋友。
那么假定新的服务器已经选好，我们来梳理接下来要做的事（按顺序）：
- 重装系统、环境、组件（Linux、Apache、Ngnix、MySQL等）；
- 鉴于镜像市场的组合可能无法满足个性需求，你可能需要手动重装一些软件，wdcp +安全狗就属于这一类；
- 在 wdcp 中新建一个和迁移前一样设置的网站和数据库；
- 新装 WordPress，然后用迁移前的备份覆盖；
- 各类权限、端口、账号密码修改回迁移前；
- 导入数据库备份；
- 重启 Apache、Ngnix、MySQL。
各点的实施细节
︱第 1 步&第 2 步——重装系统和环境比较轻松，属于全自动；软件只要符合系统和环境要求，按官方说明执行也近乎全自动；
︱第 3 步——数据库名、网站目录要与迁移前一致，数据库用户名可以不一致，但 WordPress 重装后记得更新 wp-config.php 文件；
︱第 4 步——可以直接删除新装的 Wordpress 然后重传备份资源；
︱第 5 步——Wordpress 网站根目录下的 wp-config.php 文件需要重新配置；以前手动修改过权限的文件需要再次修改；
︱第 6 步——如果还使用的 wdcp，这里有两种情况：
- 迁移前通过 phpmyadmin 导出的 .sql 格式数据库备份；
- 迁移前通过 wdcp 自带的数据库备份功能下载的备份压缩包；
第一种只要迁移后再进入 phpmyadmin 选择网站表项导入即可（注：如果直接导入 .sql 文件失败，可先压缩成 .zip 再尝试）。
第二种情况，当初网上找了一堆教程，结果没一个好使，最终自己还是捣鼓出来了。
要先看看这个 wdcp 备份压缩包的结构，了解了解：
\www\wdlinux\mysql\data
\www\wdlinux\mysql\var
这时需要：
︱一，先把压缩包解压出来；
︱二，把 「var」 文件夹里的内容全部拷贝到 「data」 文件夹里；
︱三，把 「data」 文件夹里的内容全部上传到 /www/wdlinux/mysql 路径下；
重启 Apache 和 MySQL 即可：
# service httpd restart
# service mysqld restart
最后，祝你身体健康，再会！
