ZStack实践汇 | OMG锅从天降!物理机误删除后的惊情5分钟...

发布于:2021-10-17 16:36:09

作者:ZStack社区张新光


背景

一早收到公司员工说云主机添加云盘无效,扩容内存也无效。按照之前的经验,扩容内存肯定没有问题。添加云盘需要在linux操作系统下手动挂载分区扩容。但是内存应该只要*艟涂梢粤税伞R裁欢嘞耄热缡遣皇窃浦骰啵课锢砘试春木∮忻挥锌赡苡跋炷诖胬┤荩
好吧,那就登录看看吧,小公司,基本上一个管理员密码,大家都能用。果然云主机的确很多,基本上一个服务一个云主机,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账号密码

我们需要知道数据库的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


说明**
-f 指的是备份文件,也就是你要恢复的数据库备份数据,?mysql-root-password 是数据库root账号密码参数,后面跟着的就是mysql数据库root账号密码啦,我这里没有修改过默认密码所以就是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应该有可视化的备份恢复功能,可惜我用的是社区版。数据库理论上来说只是存储逻辑数据,比如云主机的记录。云主机的物理机文件应该是存储在物理机的物理硬盘上,删除只是逻辑删除,也就是数据库删除了记录而已,其实云主机都在,所以通过数据库恢复是可以达到恢复效果的。一定要做好备份,尤其是数据库,建议要做异地备份,避免硬盘损坏。但是如果硬盘损坏,备份数据库也没啥用吧,毕竟真正有意义的是云主机的物理文件数据。

相关推荐

最新更新

猜你喜欢