记录一次汗流浃背的网站回滚

起因

昨晚，猛然间发现halo的邮件通知服务没有开通，于是乎开始研究相关事项。一开始是打算用gmail当smtp服务器的，但是研究发现这个功能好像对个人用户关闭了，遂作罢。于是盘算着要不干脆自己在服务器上搭一个邮件系统，这时我隐约记得1panel的应用商店里有相关的服务，便兴冲冲地打开1panel准备大干一场。

经过

然后噩梦就此开场。当我输入1panel的地址后，浏览器转了一会，然后给我返回了503错误代码。我直接傻了，虽然以前1panel也不是没有崩过，但是好歹还是能有个大概的界面的，我还是第一次遇到返回503的情况。我的第一反应是坏了，不会是网站被打了吧，于是赶忙登上cloudflare看看情况，但是发现一切正常。我又想是不是只是暂时性抽风，于是清除了cookie，再次尝试访问，然而并没有什么用，还是503。为了确认服务器的状况，我又尝试访问服务器上的其他内容，然而其他的服务都很正常，唯独1panel怎么弄都登不上。于是我心一横，决定直接重启服务器，俗话说重启解决99%的问题，这一次·······很不幸是那1%。重启过后的服务器依然不能登录1panel，1panel的界面依旧返回503。无奈之下，使用ssh登录服务器看看到底是什么情况。

通过翻阅1panel的相关文档，发现可以使用1pctl status 来查看当前1panel的运行状态，结果返回了一个绿色的running ，说明1panel一切正常。这直接给我整不会了，明明运行正常，那为啥会给我返回503错误代码？于是我接着试着用1pctl reset 重置系统信息，依然不行。最后我实在没有办法了，想着大不了我重装一次1panel总不会再有问题了吧？殊不知，我将会因为这个大胆的决定而折腾一天。

原本我以为，1panel只不过是一个服务面板，就算删除也不应当影响到服务器中的docker。事实证明我太天真了。在1panel应用商店中安装的docker应用，很多情况下都会把容器内部的目录映射到1panel的data文件夹下，这就导致了在删除1panel的同时也会删除这部分数据。我这里是直接把mysql的数据删了，导致所有依赖mysql的容器都出现了问题。

不幸之中的万幸是服务器上最依赖mysql的应用就是halo了，而halo的数据我每天都有备份。用官方的说法是halo的备份恢复不依赖环境，在任何部署条件下都可以恢复，哪怕数据库不一样都可以。而halo的备份恢复也很简单，只要在备份界面上传备份文件即可。不过这里也让我满头大汗了一会，因为这里说是可以直接通过下载地址获取备份文件，我就直接把服务器上的备份文件的下载链接填进去了，然而结果是虽然系统提示我恢复成功，实际上没有任何变化。最后不得已只能把备份文件下载下来，再通过上传窗口传上去才让恢复机制起了作用。说实话当时挺忐忑的，要是这么干都不行恐怕我估计就直接自暴自弃直接放弃博客了。

结果

在忙活了一通之后，总算让网站恢复了正常。又是一通手忙脚乱，1panel也重装成功，当我以为一切都可以结束的时候，1panel又给我弹出了503错误。我不知道该如何形容我当时的心情，绝望？无奈？还是一种无力回天的自嘲？不过冷静下来后，我终于开始认识到问题可能不是出在服务端，可能出在我这边。我的手中有2个梯子，一个主用，一个备用。主用的梯子什么都好，就是不知道为什么登录不上Googlecloud，而备用的梯子则可以做到这一点。那天我用过Googlecloud，于是一直使用的是备用的梯子，而我平时都是使用主用梯子登录1panel的。想到这，我赶忙把梯子切换回来，结果不出所料，这次成功登录了。看着那熟悉的界面，我感到一阵恍惚，想说点什么又无语凝噎，只好自我安慰到至少结果还不错，就当是长个记性了。

ps：我想了很久也想不明白我又没有做屏蔽规则，为啥一个梯子能登录一个不行？想了半天可能觉得是加密的问题？因为我之前都是偷懒直接用ip和端口号登录的，难道那个备用梯子不支持非https？于是我去nginx中设置了一下，将1panel映射到一个二级域名下，结果备用梯子就可以顺利登录了······就当是这样吧。