起因：
某日没有睡午觉，非常疲惫，由于工作不是很忙，遂学习起了golang。我的学习环境是放在阿里云服务器上，本地连接远程学习开发的，在配置和移动资料的过程中，希望清空某文件夹的时候，疲惫不堪的我不小心手抖将 rm -rf * 输入成为了 rm -rf /* 。瞬时屏幕上出现了一堆log，我也瞬间反应过来我干了什么好事，于是以最快的速度按下了ctrl+c，但无奈为时已晚，输入 ls 提示命令未找到，几分钟之后，服务器彻底失去响应，系统彻底奔溃。
现状
1、部分系统文件被删除，导致无法正常启动并进入云服务器，使用VNC连接后发现已经是grub rescure。 2、大部分文件可能还有保留在服务器的云端硬盘上，其中可能包括我关键的MariaDB的数据库文件、 varwwwhtml 文件夹。 3、我没有为服务器做任何快照备份。
目的
把www和把数据库的数据文件捞出来。
解决过程
1、联系客服
没错，这种事情我当然是束手无策了，这个时候联系客服看看能不能要回这台云服务器的硬盘数据，如果运气好的话，也许可以从这块已经不能启动的硬盘数据里找回些什么。 不过，得到的回答缺是，你可以给现在的硬盘数据打个快照，挂载到另一块云盘下面用另一台服务器读写，看来还是要自己操作。他的这个解决方案也不是不能用，那么结下来我就进行下一步的操作。
2、挂载损坏的系统盘到其他服务器
我进行操作的步骤如下： ①、创建已损坏的系统盘的快照。 ②、新建一台七天的云服务器，感谢阿里云让我少赔钱，记得以前最短一个月来着。 ③、新建一个云盘，选择从刚才备份的快照进行初始化。 ④、进入新开的服务器尝试挂载云盘。 当然，如果事情都那么简单的就能解决，我就不会希望世界毁灭了。
3、挂载失败后的再次尝试
再我通过各种命令，诸如 df -h、fdisk -l、ls dev|grep vd、lsblk 查到了我需要挂载的设备是 /dev/vdb3，文件系统应该是xfs，随即进行 mount -t xfs /dev/vdb3 /rescure ，但结果是一直报出关键字为：“ mount: wrong fs type, bad option, bad superblock on ” 的错误后，我随即再次联系了阿里云的工程师，在和工程师电话沟通，多次尝试后，结果仍然是报这个错误，于是工程师不太自信的推断，rm -rf /* 的时候导致了文件系统的损坏，让我们分开尝试，找到办法后再联系。
我大概是黔驴技穷了吧，我想着。
但是不继续尝试，就不会有结果，于是我在次多尝试了几次搜索后，终于在一篇关于 xfs 的帖子中，找到了在 mount 命令下加上 nouuid 选项的操作。
mount -t xfs nouuid /dev/vdb3 /rescure
终于 挂载成功。
4、查看残余有效文件
万幸挂上来了，赶快找到 /var/lib/mysql、/root、/var/www/html，我运气不错，数据都还在，只是用来存放证书和配置的 /ca、/etc 目录已经不见了，看来所有的web服务是需要重新配置了。
5、迁移有效文件
①、重建旧服务器，不过这次选了Rucky Linux 8，希望可以比Centos 8流畅些。 ②、将步骤4的三个文件夹打成压缩包，当然先把部分不用的文件夹删掉，比如 /root/.cache 之类的。 ③、使用scp或者WinSCP将压缩包转移到新建的服务器。 ④、将 /var/www/html 的文件解压到对应目录、将 /root 的文件解压到对应目录，mysql的先不能动，否则就会很麻烦。
6、MariaDB数据库的文件式恢复
首先重新安装MariaDB，然后重新初始化数据库，成功进入数据库后： 将所有需要的数据表的文件夹和 ibdata 文件恢复到对应的mysql目录 然后重启数据库服务，才可能成功从文件恢复数据库。
7、各项服务重新搭建恢复
这里就不赘述了，无非是安装httpd，配置证书、vhost和反向代理一类的操作。
总结
上面每一步，都是重新尝试了114514次后得出的结论，毕竟，没人会没事 rm -rf /* 。 记得定期给服务器打个快照，这样就算丢失了一篇博客也没啥大不了的。 没事别碰公司服务器。