由于工作需要，在云服务器上系统盘上安装了wiki服务为公司内部提供可供交流的公司文档，通常用于日报、周会总结等。
事件开始
前几日开始cpu便显示90%多的利用率，而之前平均也才15%左右，刚开始没有太在意，心想可能是因为wiki用的功能越来越多，所创建的线程较多从而导致的，还有一点就是因为服务器本身配置不高，内存没有达到wiki的推荐。
事件发展
某晚发现wiki服务终止，无法通过远程工具ssh连接服务器，通过阿里云网页版的远程工具发现可以连接上，查询后发现是因为cpu利用率太高导致wiki的进程被杀死。同时发现了有异常的进程不断的占用着cpu的资源，于是杀掉了异常进程，同时重启wiki服务，cpu消耗降低，wiki服务正常。
第二日早发现wiki服务再次终止，昨晚杀掉的进程自动启动不断的占用cpu的资源，还是昨晚相同的问题，于是开始意识到了事情的严重性，由于无法直接远程上去，通过网页版修改比较麻烦，于是想直接重启机器，因为wiki和数据库设置成开机启动，所以重启之后应该正常可用，然后通过wiki网页版的备份恢复功能将文档迁移到新的机器上，然后再把原机器删除即可。
大问题
重启服务器之后遇到了大问题，无法通过远程ssh登陆到服务器，通过阿里云网页版登陆服务器之后发现大部分指令执行之后都被killed，程序无法启动，linux大部分命令是用不了如netstat、chown等，而yum、wget提示权限不足，scp提示网卡出错，这个问题十分诡异一开始以为是强制重启导致的系统文件丢失，后来排除了这个可能，通过和阿里云技术一同排查和沟通，怀疑这几天的机器异常可能是因为被黑客侵入，在服务器上运行恶意脚本如挖矿脚本，重启服务器之后恶意删除系统文件造成系统损坏无法恢复所造成的。查看文件夹，幸好wiki数据库文件没有被删除，但虽然现在数据还在服务器上，但是现在机器几乎所有指令都无法使用也无法安装指令，怎么将数据拿下来然后导入到新环境中成为了一大难题。
拿回数据
根据和阿里云技术讨论虽然由于作为系统盘的磁盘无法使用，从而丧失了对虚拟机的控制，但是如果仅仅是要恢复数据的话，可以将这个系统盘挂在到另一台系统盘正常的机器上作为存储盘，然后再将数据取出即可。
1、创建原系统盘快照，（一定要创建，否则无法找回数据），确认系统盘的快照已经创建完成。
2、购买新的云盘，购买【和服务器处于相同可用区】的云盘，选择从快照创建磁盘（即将快照的数据拷贝到了新的磁盘中）注意：初始化系统盘后，目前服务器系统盘里的数据和应用就没有了，需要再重新配置应用。
3、购买新的服务器。
4、将第二步购买的快照盘在控制台上挂载到服务器上，然后就可以通过登录这台机器，从新创建的数据盘中拷贝出来。
创建用户挂载磁盘的文件夹data
mkdir data
fdisk -l
mount /dev/vdb1(磁盘名) /data
挂载磁盘到data文件夹。
成功之后只要进入到data文件夹即可得到原虚拟机所有的数据信息。
我通过这个方法，拿回来数据库内所有的的数据（mysql文件夹，在my.cnf中记录了数据文件的目录），以及wiki源文件信息，文件夹路径信息，图片信息等
恢复服务
拿回了数据库的所有文件和wiki的所有文件即可在另一台机器上搭建wiki服务。
如何通过源文件恢复数据库信息如mysql查看百度寻找方案，而我是在本地新装了一台数据库，将原数据库的mysql文件夹替换掉新装的数据库的mysql文件夹，然后启动mysql，查看是否能正常启动，若无法正常启动，则进入mysql 的日志目录查看日志中是否记录着异常信息。
wiki文件夹主要包含两个主要的文件夹，迁移方案在网上也有比较多，一开始我想让wiki直接连接到新版本的数据库，发现服务不可用，后面则采用和旧版本相同的数据库，于是正常。
至此服务从被破坏到恢复完成。
这次的经历给我很多经验
（1）我一直知道网络黑客，但是我却认为网络入侵这样的事情不会发生在我身上，没什么防范意识
（2）服务器和数据库应该分离部署，原来服务器和数据库是部署在一台机器上面的，如果服务器出现问题，那么数据库也会跟着遭殃，如果一开始我们的数据库可用，那么将节省很大时间。
（3）所有线上的业务做到每日备份，这些东西都要做到每日备份，一旦遇到相同的事情，也只需要备份恢复，就可以恢复前一天的状态，从而节约很大的时间。
（4）开通防火墙，安全中心等阿里云上的安全产品，这些是很有必要的，否则建议还是放在内网部署。