在之前，说到了系统的重装，我打算趁此机会一并升级了系统及相关软件。
我首先去服务市场看了下现有的镜像，发现有一个是 centos 7.2，php 7.0 的 wordpress 建站模板镜像，基本满足了我的需求。
怎么说好呢，其实我还想最好也有 jdk 及 tomcat 的，但 php 的组合一般是 php + apache + mysql。也有一些全功能的镜像，但是又没有 wordpress。
总之，平台提供的策略还不是很灵活，我也不知道这到底应该叫什么 aaS，或许是 PaaS，或许是 IaaS，我希望的理想方式是有一个类似的表单，有很多的下拉框，我可以在其中选择，比如选择了 php 7.0 + wordpress 4.7 + mysql 5.7 + apache 2.4 + jdk 8.0 + tomcat 8.0，然后你作为平台就给我生成一个镜像出来。
但目前来说，好像还不支持这种细粒度的配置。当然，有人会说，那你安装一个最基础的 centos，然后自己去配置好了。这样确实是可以的，可我已经厌倦了去做这些，我的目的并不是要成为一个运维的专家，我只是需要一些服务而已！
我之前的系统是有 php 和 jdk 的，当然 jdk 也是我自己弄上去的。说实话这些弄一次你还有新鲜感，弄多了就没意思了。但目前也只好先顾及了 php 的运行环境，至于 jdk 之类的就只好再说了（又得有一番折腾！）
安装镜像的过程还是很顺利的，为了降低熟悉的成本，我还特地选了同一家服务商提供的镜像（我现在这个损坏的系统也是这个服务商的镜像），不过还是有些区别，后来还因此吃了不少苦头。
首先它没有初始化 wordpress，而我记得上次的有的，而且好像还把 admin 的密码一并提供在了一个说明文件里了。不过这个系统已经在重装中被干掉了，所以现在也没有办法去确认这一点了。当初就不应该轻率的只备份了 wordpress 就重装了，最好是把一些配置的也备份，比如 apahce 的一些配置，其实我是做过一些调整的，现在都没有了，要是备份了，到时有问题做个参照也好。
那就自己初始化它吧，结果我就遇到了第一个坑。初始化过程 wordpress 会让你提供数据库连接的信息，我就照着说明文件中提供的用户名，密码以及数据库名填了上去。
其实我觉得这次的镜像很不专业，没有 root 之外的用户，数据库名没有改，直接叫 wordpress。上次是提供了随机的数据库名给 wordpress 用，而且专门只为这个库提供了一个随机的用户。因为急着恢复，也没有去计较这些了。
还有 host 名，我直接保留了表单中缺省的 localhost 的值。结果却是初始化失败，一直说连不上数据库。我就奇了怪了，首先想到可能是密码填错了，反复试了几次，确认绝对没有填错后，只好思考其它的可能性了。
只好是 putty 到后台，查看了一下 mysql 服务，没有问题，正在跑着呢，在它的命令行中用 root 也能登录，wordpress 数据库也有，为啥死活就是连不上呢？localhost 也没有拼错呀，正百思不得其解时，突然一激灵，难道要用 127.0.0.1？填上去一试，果然就 OK 了！
真是无语呀，估计内部 host 没有把 localhost 和 127.0.0.1 对上，能连上就行了，暂时放过它。
我后来去查了镜像附带的手册，截图里果然也是填 127.0.0.1，唉，谁会想到这个缺省的 localhost 居然成为了问题。
初始化 wordpress 后，已经能够通过浏览器访问了，不过还没有数据。因为它是 4.7.4 版本吧，而最近 wordpress 又升级到了 4.7.5，于是想顺便也把它升级了，结果又是报之前也老是遇到的问题：连不上它的升级服务器！
按照它报的错，貌似 https 的通讯被阻隔了，可是相关端口我已经是放开了的，内部用 wget 也能抓到 https 的数据，实在不清楚咋回事，只好先放开了所有端口，终于是愉快地连上并升级了。
接着就把 backup 的插件给装了，自然也是最新版了。在此之后，我还给这个环境做了一个镜像。再之后就开始恢复数据了。
先把之前 backup 的数据包上传，因为备份插件的 web 页面不支持超过 2M 的文件上传（真是莫名其妙，也许是免费版的缘故吧，反正它也没有提示），只好切换到 ftp 上传，传完后开始恢复，结果又报错了，说没有权限操作上传数据所在文件夹。
这个问题其实我之前也有提过，主要原因就是 apache 是用某个特定组的特定用户的权限来运行的，而我操作 ftp 时是用 root 用户，所以上传的文件及文件夹 owner 之类的都变成了 root。
其实它确实了提供了相应的 ftp 用户，跟 apahce 的一样的，可是死活连不上，只好用 root 来上传，然后调整 owner，group 之类的，chmod 把权限设为 0755 等，又是一通折腾。
把权限之类的理顺后，再次尝试恢复，页面一闪然后就没有响应了，页面上还是之前的提示：“没有权限操作文件夹云云……”，奇了怪了，不是已经调过来了吗，ftp 上显示 owner 之类的已经是 与 apahce 的用户一致了，不放心又去到后台，ls 看了下，都 OK 了。
实在没有道理呀，只好又搬出了重启的杀手锏，servcice httpd restart，不行！干脆系统 reboot，还是不行！干脆把相关那些文件夹的权限都放到最开，还是不行！
真是让人沮丧，又不得不陷入了沉思，然后想到这些操作间还是有些区别，第一次是直接出了异常提示，而后面的几次是闪了一下，然后就不动了，当然异常提示还是显示在那里，难道这些提示还是一开始的，后来就都没有变过？！
还真有可能呀，我一直没有刷新页面，恢复动作可能发的 ajax 请求，而它又自动保持了登录状态……
赶紧刷新了一下页面，提示消失了，再执行恢复，页面一闪，然后这次没有任何提示了！！看来不是之前的问题了，真是坑人不浅呀！
赶紧到后台，在它的备份文件夹中找到了一个恢复的日志文件，一看，果不其然，发生了异常！大意是无法识别备份文件的格式，已经不是什么权限问题了！可你为何不把新的异常抛到前台显示呢！
现在回想一下，之前的异常提示或许是 wordpress 抛出的，而插件本身出异常是直接嗝屁了，没有任何提示的，又被坑了……
不过暂时已经没有心思去顾及它这个异常显示的问题了，发现了问题就好。想了想应该是因为现在用的备份插件版本更新了，所以不能识别老的版本的备份文件了？
这很不应该呀，连向前兼容都做不到？现在也没有心思去纠结这些问题了，赶紧看看能否弄到旧版本再试试。
可上哪去弄旧版本呢，在 wordpress 的插件库，永远都是最新的版本！根本没有后悔药可以吃。突然想到备份文件中就包含了这个 backup 的插件，能否从中解压出来呢？它的后缀是它专有的，但会不会是披着羊皮的狼呢？我试着把它的后缀名改为 zip，然后尝试用解压软件打开，但还是无法识别，唉，看来不是通常的格式，为啥不用通常的格式呢？现在真是拿这一包文件没办法。
看来得去网上找找这个插件的官网看看是否有老版本了，突然间又想到，好像之前手动备份过 wordpress 的整个文件夹，直接就是把 server 上的文件夹 download 下来的，应该包括了那些插件！赶紧去硬盘中翻了翻，果然有，谢天谢地，不用去网上找了。
于是又卸载了新版本的备份插件，重新上传了老版本的，自然又免不了一通改权限，然后一切顺利，跟新的 wordpress 版本也还兼容，于是赶紧又尝试恢复，这次恢复终于没有异常了，看到进度条在往前滚动，心里终于是松了一口气。一段时间后，恢复完毕，再刷新首页，一切都回来了！
看来总算是 OK 了，心里也是由阴转晴。可是等我想登录进去后台的时候，立马发现了一个严重的问题，admin 的密码是什么来着了？我已经不记得了！我依稀记得原来的密码好像是在 root 用户目录下的一个文件上，跟那些 mysql，ftp 之类的在一起的，是它初始自动生成的一个随机密码，我一直没有改过。
可是原系统随着重装已经被干掉了，我只顾着备份 wordpress 的相关数据，却忘记了那些东西了，真是糟糕。
现在都没有办法登录了，因为我本地也没有记录那个密码，一直都是让浏览器记着的，可是刚才因为安装了新的 wordpress，生成了新的密码，把之前记的冲掉了。唉。
看到它页面上有一个找回密码的选项，我赶紧点了一下，结果它说发送邮件失败！真是流年不利，我记得明明配置了我的邮箱的，也许还有什么地方没有配置上，或许直接到数据库里调整一下？亦或是直接到 user 表里把 admin 的密码干掉？它的密码保存策略是什么？要是简单的 md5 就好了，要是又跟用户名绑定，又加了随机盐之类的，那可得又要折腾一番了！
脑子里快速闪过一些想法，一下子也想不清楚那种方式会更顺利些，突然脑子里又冒出一个新想法，虽然我这个浏览器的密码被冲掉了，可我还有好多的浏览器，似乎也登录过，而且应该也是让它们记住了密码的。
我赶紧启动了 firefox，进入登录页面，用户名和密码就自己填上了，果然记住了，一按登录，进去了！真是高兴呀，又赶紧尝试重新生成了一个新密码，谢天谢地，不用再次输入原密码，否则又要到 firefox 中扒拉一通了。
之后再用这个新密码，chrome 中也能登录了。吸取了教训，这次赶紧把它记录到服务器中以及本地。
因为恢复的缘故，wordpress 又降到了之前的版本上，看来先前不应该早早升级的，现在又得再升级一遍，好在一切顺利，于是把其它的插件也上传并升级了，再刷新首页，代码高亮等效果也 OK 了，心想这下总算是好了。
至此似乎一切 OK，也因为有点累了，所以也稍微休息了下。可事实证明我高兴得有点早了。等休息回来想再确认一下一些细节以及顺便测试一下在新环境下的响应速度等时，又发现了一个严重的问题，那就是点击任何的文章，都报 404 错误。
首先数据肯定是有的，不然首页中也不会预览出来了，但进去具体文章页时却报错了。从它报错的情况来看，我断定它是 uri encoding 的问题。
因为我采用的固定链接形式是后接文章名的形式，而因为很多文章标题都带有中文，所以 url 都是有很多 utf-8 的转义表示的，但它的 404 错误提示里，这些转义的都变成了 iso-8859-1 的字符，然后说找不到页面，所以我怀疑是 uri encoding 方面出了问题。
然后又是找 apache 的那些配置文件左看右看，又是 google，又是到它的官网去查，忙活了半天，结论却是让人沮丧的，那就是 uri encoding 的配置看上去并没有什么问题。
毫无头绪，又只好在页面上乱戳，嘿，还真让我戳出了头绪，我发现连 about 页面也是 404，这可是完全是英文字母的一个链接，肯定不会是 uri endoing 的问题了！
看来又一次被带到坑里去了！我赶紧新建了一个完全英文标题的文章，首页显示还是 OK 的，可是再点击时还是 404，不过现在就可以肯定 404 的问题与 uri encoding 无关了。
至于之前的提示出现的 iso-8859-1 的字符，看来可能是异常处理过程中瞎乱解码造成的！这些蹩脚的提示真是让人窝火，你按 url 转义的原样显示不就完了，瞎乱解码干什么，又把人带坑里去了……
现在看来是其它的配置导致的问题了，可到底是 apahce 的锅，还是 wordpress 的锅，而中间又夹杂着升级与恢复，一下子不好断定到底哪个环节出了问题。
现在突然有点懊悔，当初升级了新环境，应该多测试一下是否存在各种问题先的。特别是在固定链接方式上，我是改变了 wordpress 缺省的方式的。这个新系统是否一开始就存在缺陷呢？亦或是我恢复以及再度升级引入的新问题？我现在也说不上来！
看来现在要倒车回去一一排查了，唉！不过想到现在数据大体恢复过来了，因为经过此次折腾，对 backup 插件也有点不放心，于是手动对恢复的数据再进行了一次备份，包括数据库也自己导出了一下。
然后，就准备启动时光机，要开历史的倒车了。真是麻烦呀！不过好在之前做了一个初始环境的镜像，所以又是一番折腾，恢复到了上次的镜像去，此时还没做数据恢复，只是简单升级了一下 wordpress。
简单做了下测试，发现保留缺省的固定链接跳转方式，就不会有 404 问题。可是一旦进入 wordpress 后台调整了固定链接的方式，也即是调整成我之前一直用的方式，404 又出现了！
看来确实不是恢复过程带来的锅，很可能就是镜像本身的锅，不过因为我在服务商提供的原始镜像后又升级了一下 wordpress，尽管这其实只是一个很小版本的升级，相信不会带来问题，可是我也不想冤枉一个好人。
怎么办呢？我决定彻底恢复到服务商提供的原始镜像去看看，于是再次关机并重装了最开始的镜像，然后简单初始化了 wordpress。
因为前面已经踩过了一些坑，谢天谢地，这次很顺利。然后其它我都没有去动了，也没有去升级 wordpress。
再次测试，发现后台调整了固定链接的方式后，还是有 404 错误！看来确实是这个镜像本身的缺陷了。
我说过我我不想去冤枉一个好人，可现在我想说，这所谓 wordpress 建站模板的镜像打得也太不专业了！你在 wordpress 管理后台调整了一下固定链接的方式，它就不能正常工作了，你说坑爹不坑爹？
不过情绪归情绪，现在的迫切问题是赶紧让系统恢复正常。可现在却陷入了一个困境当中。很明显，镜像有缺陷，可它到底是因为一些简单的失误还是说是一个很复杂的原因呢？一时也无从判断。
现在面临的一个抉择就是，到底要不要去深入调查这个问题？让人恼火的地方也正是在这里，如果你采用一个镜像，你只是想它所提供的快捷的服务而已。理想情况下，它对你就是一个黑箱而已，你肯定不希望去深入到它里面去。
如果你还要去调查别人的问题，又不是你亲自配置的，对你而言你也不熟悉，所以也许你会想，我干嘛不换一个呢？我当时也是这么想的，而且一系列的不顺利让我对后续的稳定运维也有了一定的担心，也许此时去升级确实不是好的时机？
脑子里此刻又冒出了一些保守的声音，或许还是先回到之前的系统，把数据恢复好为先。而正好我给先前的系统也做过一个镜像，那时还不存在 CPU 的占用问题。于是我决定先回到更早的那里去试试，此时也不想去升级什么 php 了。
当我再次把系统倒腾回去那个镜像时，却惊讶的发现它也不能正常运行了，更别说什么恢复数据了！真是祸不单行！
我向毛主席发誓，当初制作那个镜像时，系统运行肯定是 OK 的，如果不 OK，谁会去制作什么镜像呢？对吧？
客观的讲，这个镜像距今有段时间了，可我拼命回想，也想不出期间有什么重要的环节有了改变，以至于它都不能成功运行了！唉，真是倒霉，此刻我又面临一个抉择，那就是去调查这个旧系统的问题，还是回到之前去调查新系统的问题呢？亦或是再看看有没有新的选项？反正都没有头绪！
可以说，我此刻对镜像恢复的可靠性的信心也下降了，这是贝叶斯定律告诉我们的，每失败一次，你的信心就应该相应下降！
现在该怎么办？没错，我又摇摆回了升级的选项上，反正横竖都有问题！如果要去解决旧系统的问题，那还不如解决新系统的问题，对吧？不过我还是再次去服务市场逛了逛，看看是否有更好的选项。可看来看去，选择并不多，最后，我不得不决定还是回头去尝试了解一下 404 的根源。
当然了，现在我不会急着先把系统倒腾回去了，先把问题调查清楚再说。于是在 google 上搜索了固定链接调整后的 404 问题。果然，有挺多人遇到了这个问题，再稍微深入了解了之后，发现或许就是 apache 里忘记配置一下转发规则导致的，看来并不是什么复杂深奥的问题，也许只是一个愚蠢的失误而已！
我现在都有点后悔了，为啥当初不先尝试了解一番，而是急急忙忙地回滚呢？不过现在说这些有点马后炮的意思了，唉，不管了，先倒腾回去再说。
呵呵，于是又是一番折腾，我都有点心疼云上的那些硬盘了，不过它们看来还是蛮快的。
当再次去 apache 里检查那些转发规则配置时，发现还真是没有配置！叫我说什么好呢？！
为了顺利升级，我还特地选了同一个服务商的镜像，可你之前的镜像都有配置，为啥这次又没有了呢啊啊啊？残酷现实再次打脸，我又一次因为信任别人而被坑了！
只好自己改了那些配置，重启服务并调整了固定链接的配置后，依旧能正常跳转了，404 消失了！于是又折腾一番恢复了数据，又再度升级了 wordpress，又升级了所有插件，跳转还是 OK，再没有 404 的问题了。
至此终于是系统也顺利升级了，数据也恢复了。吸取之前的教训，额外多测试了许多功能，确认都没有问题，于是终于放心了。然后用 backup 先备份 wordpress 一遍，手动再备份一遍。然后整体系统再做一次镜像。
没有办法，麻烦是麻烦了些，踩过一些坑后，你不得不多留些心眼！有备无患，多多益善！
这次故障处理及顺带升级的过程就是这样了，应该说还是带来了不少的经验教训的，所以啰啰嗦嗦特作此文以记录。
