背景

一早同事说之前搭建的zstack上的云主机云盘以及内存扩容无效。按照之前的经验，扩展内存肯定没有问题。添加云盘需要在linux操作系统下手动挂载分区扩容。但是内存应该只要重启就可以了吧。

登录zstack查看下，当前zstack只是试用，没有什么管理，一个管理员密码，大家都能用，所以云主机的确很多。基本上都是一个服务一个云主机，nexus、gitlab、mysql、oracle等等。而且分的基于都是4-16（4CPU,16G内存）。本着节约资源，想删除自己创建的一些无用云主机，整合一些公用的云主机。好吧，问题由此而来，操作失误。

问题原因

登录咱就不提了。这里要说的是，zstack开源版本，用户管理都没有，权限也没有，这个有点说不过去啊。这也是导致误删物理机的原因之一。总之我用了管理员账号登录查看某台物理机。想着先看看物理机下的云主机占用了多少资源，是否可以删除一些。

• 重点在这里

从物理机进入查看当前物理机下的云主机，是挺乱的。我的本意是想删除云主机，所以我选中了云主机，点了删除。问题来了，以前经常删除云主机，所以没太在意弹出的确认框。好吧，是我疏忽了。关键是我点的是物理机操作下的删除，天啦，我把物理机删了，物理机的云主机都丢了。

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

解决方案

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

• 首先我是在物理机中重新加了被我误删的物理机

这个咱也不提了，添加物理机咱们应该都懂

• 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账号密码。如果zstack安装后没有修改过密码的，那么root账号的默认密码就是 zstack.mysql.password 。
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

恢复命令说明

-f 指的是备份文件，也就是你要恢复的数据库备份数据，--mysql-root-password 是数据库root账号密码参数，后面跟着的就是mysql数据库root账号密码啦，我这里没有修改过默认密码所以就是zstack.mysql.password

• 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就可以看到云主机恢复了，还需要见证下奇迹，启动恢复的云主机，成功了。哈哈！

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

总结

1. 整个过程还算顺利，没啥特别的坎坷
2. 管理员权限太大，操作要谨慎
3. zstack的UI有时候也是挺绕的，有些UI交互模块化不是很清晰，比如当前菜单模块是物理机，同一个页面上既可以操作物理机，也可以操作云主机，用户体验是大大提高，但也带来了风险。
4. 数据库理论上来说只是存储逻辑数据，比如云主机的记录。云主机的物理机文件应该是存储在物理机的物理硬盘上。删除只是逻辑删除，也就是数据库删除了记录而已，其实云主机都在。所以通过数据库恢复是可以达到恢复效果的。
5. 备份，一定要做好备份。尤其是数据库，建议要做异地备份，避免硬盘损坏。但是按照总结4，如果硬盘损坏，备份数据库也没啥用吧。毕竟真正有意义的是云主机的物理文件数据。
6. 整体来说，zstack使用起来还是很不错的，整个恢复过程也非常快，恢复操作也很简单，输入命令后就安心等待恢复就好了，基本上接近一键恢复了，整个恢复过程也就5分钟左右吧，我估计企业版的UI应该就有可视化的备份恢复功能。可惜我用的是开源版