0x01 前言

晚上心血来潮向更新首页,发现本站所用的wordpress模板的demo有个样式非常合适,在进行测试的时候无意间导入大量文章,于此同时对通过邮件订阅我博客的朋友发送大量通知邮件,造成极其严重的影响。

经过一番折腾,我发现模板厂商自开发的编辑器存在问题,在编辑的时候会出现大量js错误,导致一些功能无法正常使用,使得我的页面破破烂烂。正想放弃的时候发现原来的首页数据已经丢失,而且媒体库和文章库等被导入大量demo数据,同时数据库也遭受“污染”,已经无法通过常规方法还原。

所以,这次事故被定性为生产事故,需要紧急进行灾难恢复。因为我的博客数据每天备份,所以只需要还原到前一天的数据即可。

0x02 web服务器

我是用netbackup(下称NBU)对虚拟机进行备份,通过NBU对接vCenter,从而调用vCenter的API进行虚拟机的快照工作,最终将快照数据存放到NBU的数据存储中。

因为我服务器的磁盘空间较为庞大,所以web服务器备份我都以全量备份进行。对于web服务器,而且其没用任何依赖关系,web服务器中运行着lsync会将另一个web服务器中的脏数据同步删除,所以直接还原即可。首先找到相关备份文件:

而后选中镜像并单击恢复按钮,在弹出的对话框中确认还原到原始路径:

确认数据的传输途径,具体请参考软件文档,如果不确认,可以全选,但在某些情况可能不是最优选择或者出现一些奇怪的问题:

紧接着勾选还原虚拟机BIOS UUID和实例UUID,覆盖到当前的虚拟机位置,移除光盘驱动器、串口等信息,建议选择精简置备的磁盘模式,可极大程度提高磁盘使用率,但对IO密集型的虚拟机会带来IO性能稍微下降的问题:

在实施还原前需要进行检查,通过后即可开始:

接下来可以切换到任务进程视图,检查任务执行情况:

还原流程结束后再回到vCenter启动虚拟机即可。因为是全量备份和全量还原,同时该虚拟机中运行的服务没用任何依赖性且没用部署集群等,所以还原过程较为简单粗暴。

0x03 数据库

数据库有那么一点点复杂,因为数据库是以MariaDB Galera集群实现的多master同步需求,我的集群共有3个节点,均为master。

因为数据已经被污染,也就是说数据已经同步到各个节点。如果直接还原我家中的节点,因为备份时间为前一天,最终在数据库启动的时候会拉取其他节点包含脏数据的版本到本地,无法实现数据库还原的目的。

所以解决问题的流程是:

  1. 保留现有数据库集群节点
  2. 将前一天的备份还原至其他地方并重命名
  3. 从还原的数据库中dump数据库数据
  4. 删除现有节点中的数据
  5. 导入前一天的数据
  6. 等待同步,完成

NBU还原历史备份的流程与web服务器类似,但在开始时需选择备用路径:

在传输方式界面还需要选择存放位置的信息,并且建议更改虚拟机名称:

后面会检查数据存储:

要求选择合适的端口组:

最后是测试:

完成还原工作后,在启动虚拟机前需要删除虚拟机的网卡,因为我的数据库是设为系统启动后自行启动的,而后会自动加入数据库集群;另外,网卡是手动模式,需要将其修改为DHCP模式,以避免IP冲突的问题:

建议删除还原的网卡并重新添加,避免MAC地址重复。网卡使用nmtui配置:

最后删除MariaDB配置文件中galera集群的配置信息:

完成后重启虚拟机,确认MariaDB启动后即可使用mysqldump命令导出数据并通过sftp等方式传输到生产环境集群中的某一节点里。

在生产环境的节点中删除相应数据库的所有表,最后导入即可,数据会自动在各个节点中同步。

0x04 结语

受限于机械磁盘IO的问题,数据还原用了20多分钟。最终,经过半小时的紧张折腾,我的博客恢复了。

在此向遭受邮件骚扰的订阅者们道歉,下次类似的测试会在隔离的测试环境中进行。