OMG锅从天降！物理机误删除后的惊情5分钟……

背景

一早收到公司员工说云主机添加云盘无效，扩容内存也无效。按照之前的经验，扩容内存肯定没有问题。添加云盘需要在linux操作系统下手动挂载分区扩容。但是内存应该只要重启就可以了吧。也没多想，比如是不是云主机太多？物理机资源耗尽有没有可能影响内存扩容？

好吧，那就登录看看吧，小公司，基本上一个管理员密码，大家都能用。果然云主机的确很多，基本上一个服务一个云主机，nexus、gitlab、mysql、oracle等等，而且分的都是4-16（4CPU，16G内存）。本着节约资源的想法，想删除自己创建的一些无用云主机，整合一些公用的云主机。好吧，问题由此而来，操作失误，物理机被删除了！！

问题原因

我们使用的是ZStack社区版，我用了管理员账号登录查看某台物理机。想着先看看物理机下的云主机占用了多少资源？是否可以删除一些？重点在这里，从物理机进入查看当前物理机下的云主机，是挺乱的。我的本意是想删除云主机，所以我选中了云主机，点了删除。

问题来了，以前经常删除云主机，所以没太在意弹出的确认框。好吧，是我疏忽了。关键是我点的是物理机操作下的删除。天啦，我把物理机删了，物理机的云主机都丢了，怎么办？公司好多服务啊，这个锅我背不动啊。

冷静，ZStack还是很稳定的，用到现在体验也不错，一般这种问题估计也不止我一个，肯定有策略恢复吧，于是赶紧去ZStack社区QQ群里咨询下。

恢复

上面都是废话，这里才是干货请教大神后果然有恢复策略，废话不说，咱们直接看操作过程吧。

首先，我是在物理机中重新加了被我误删的物理机。这个咱也不提了，添加物理机咱们应该都懂。

ssh登录master物理机先找到数据库备份物理存储路径：

cd /var/lib/zstack/mysql-backup/

查到所有的备份数据，还好昨天凌晨有备份。惊喜万分！

-rw-r--r-- 1 root root 764449 Mar 11 12:30 zstack-backup-db-2020-03-11_12-30-01.gz

-rw-r--r-- 1 root root 739274 Mar 12 00:30 zstack-backup-db-2020-03-12_00-30-02.gz

-rw-r--r-- 1 root root 739165 Mar 12 12:30 zstack-backup-db-2020-03-12_12-30-02.gz

-rw-r--r-- 1 root root 735696 Mar 13 00:30 zstack-backup-db-2020-03-13_00-30-02.gz

-rw-r--r-- 1 root root 735784 Mar 13 12:30 zstack-backup-db-2020-03-13_12-30-02.gz

-rw-r--r-- 1 root root 730361 Mar 14 00:30 zstack-backup-db-2020-03-14_00-30-01.gz

-rw-r--r-- 1 root root 730363 Mar 14 12:30 zstack-backup-db-2020-03-14_12-30-02.gz

-rw-r--r-- 1 root root 730363 Mar 15 00:30 zstack-backup-db-2020-03-15_00-30-02.gz

-rw-r--r-- 1 root root 728296 Mar 15 12:30 zstack-backup-db-2020-03-15_12-30-02.gz

-rw-r--r-- 1 root root 744715 Mar 16 00:30 zstack-backup-db-2020-03-16_00-30-02.gz

-rw-r--r-- 1 root root 717877 Mar 16 12:30 zstack-backup-db-2020-03-16_12-30-01.gz

-rw-r--r-- 1 root root 687914 Mar 17 00:30 zstack-backup-db-2020-03-17_00-30-02.gz

-rw-r--r-- 1 root root 695441 Mar 17 12:30 zstack-backup-db-2020-03-17_12-30-01.gz

-rw-r--r-- 1 root root 713998 Mar 18 00:30 zstack-backup-db-2020-03-18_00-30-02.gz

-rw-r--r-- 1 root root 708907 Mar 18 09:44 zstack-backup-db-2020-03-18_09-44-07.gz

找到root账号密码

cd到数据库备份文件位置，我们通过命令来恢复数据库：

zstack-ctl restore_mysql -f zstack-backup-db-2020-03-18_00-30-02.gz --mysql-root-password zstack.mysql.password

恢复成功启动ZStack

[root@192-168-3-8 mysql-backup]# zstack-ctl restore_mysql -f zstack-backup-db-2020-03-18_00-30-02.gz --mysql-root-password zstack.mysql.password

check pass

Backup mysql before restore data ...

Backup mysql successfully! You can check the file at /var/lib/zstack/mysql-backup/zstack-backup-db-2020-03-18_09-44-07.gz

successfully stopped management node

Starting restore zstack data ...

successfully stopped the UI server

Starting restore zstack_ui data ...

Recover data successfully! You can start node by: zstack-ctl start

[root@192-168-3-8 mysql-backup]# zstack-ctl start

total 10676

OK了，静静等待启动成功

Starting ZStack management node, it may take a few minutes...

successfully started Tomcat container; now it's waiting for the management node ready for serving APIs, which may take a few seconds

successfully started management node

Starting ZStack web UI, it may take a few minutes...

successfully started UI server on the local host, PID[16311], http://192.168.3.8:5000

好吧，至此整个恢复过程就算结束了，我们重新登陆UI就可以看到云主机恢复了。还需要见证下奇迹，启动恢复的云主机，成功了！哈哈！

以上就是我误删的云主机，现在已经重启成功了，当然误删的云主机还有很多哈。

总结

整个过程跌宕起伏，不过在ZStack社区大神的助力下，恢复的还算顺利，没啥特别的坎坷。提醒大家，管理员权限太大，操作要谨慎。

整体来说，ZStack使用起来还是很不错的。整个恢复过程也非常快，恢复操作也很简单，输入命令后安心等待恢复就好了。基本上接近一键恢复了，而且整个恢复过程也就5分钟左右吧！！我估计企业版的UI应该有可视化的备份恢复功能，可惜我用的是社区版。

数据库理论上来说只是存储逻辑数据，比如云主机的记录。云主机的物理机文件应该是存储在物理机的物理硬盘上，删除只是逻辑删除，也就是数据库删除了记录而已，其实云主机都在，所以通过数据库恢复是可以达到恢复效果的。

一定要做好备份，尤其是数据库，建议要做异地备份，避免硬盘损坏。但是如果硬盘损坏，备份数据库也没啥用吧，毕竟真正有意义的是云主机的物理文件数据。

- END -