续上次linux恢复后续
上回说到用工具抓取碎片后续
---------------------------------------------
所写均是在学习恢复数据库技术中的成长并记录
----------------------------------------
RESTORE_flLE文件夹 是我们用工具把分析抓取的碎片 解析出来的自动生成的目录
打开文件夹后 我们发现了碎片解析出来的有当时被删除后还没有覆盖的情况下所解析出来的库
而下面散乱的ibd则是不能识别因为元信息丢失 无法恢复成原有的数据库表名
现在打开的是我们第一个库名anzhi_cloud_base ，而解析出来的大部分没有frm表结构 所以我当时想客户索要了建库脚本 客户从测试库打包了建库脚本 我们从而使用mysql运行sql文件从而得到frm表结构 然后把这个库导入mysql查看工具 查看数据是否正常 如果正常基本到这里就可以交差了
但大部分都会被覆盖一点数据 或者表结构不够完整 导致无法进行交差
下面这是另一个客户恢复记录
上面这张截图则是我昨天给客户查找的信息
因为昨天解析出来的数据都没有表结构 客户给的建表语句又不够完整 导致我们恢复遇见了难题所以才启用了另一个方案
使用WinHex对丢失数据的盘进行磁盘扫描
因为昨天数据库庞大而且丢失的情况又比较严重 所以我们克隆了一个数据库丢失的磁盘 来进行双向查找加速进度
现在我们是知道丢失数据的库名的 所以在扫描完的磁盘里使用ctrl+F 进行查找
查找CREATE TABLE `equip` (
一般情况大佬们都是会使用列出多条 然后打开位置管理器 频繁使用相关词句来扩大范围搜索 但是没办法小弟刚入门对这些不够熟悉所以列出多条反而让我思绪慌乱所以我并没有使用 相反用俩个磁盘进行双库名搜查
现在我们找到了表结构我们利用框选ALT+1-ALT+2-SHIFT+CTRL+N把他打包复制到我们的本地 因为数据已经散乱胡乱一直找完整的一个表很难 所以我们打包进行研究
现在我们用EmEditor打开
这里 我们发现了数据是有相同点的 很难查找也有很多相同数据 有很多是前面是一完整的表结构 但数据只有一半就被截断插入了的数据 所以我们只能找到截断的地方 然后根据相关信息进行搜索 现在我们找到的相关信息 (87,'120 这个87是自增按照这个逻辑我们可以查找(89,'120 (95,'220 为什么不查询88呢 因为87是截断的最后88极有可能已经被截断成一个不完整的情况了
最后我们通过这个办法 在磁盘找到了中间截断掉的数据利用框选ALT+1-ALT+2-SHIFT+CTRL+N打包回来，并将其整合一般数据量少的话基本这样就完成了，而然事情并没有我想象的这么顺利
数据量过于庞大所以中间截断的情况比较严重 最新的生产数据又不齐全无法交差
接下来我们只得重新启动方案
首先我们一开始就说道我们缺少的是表结构文件而客户给的建表脚本又不够完整所以导致我们无法恢复出来 这里其实我们是有恢复出来的数据也就是ibd数据 但没有表结构和建库脚本
所我们这里利用WinHex扫描磁盘打包出来的equip2.sql文件 用数据库运行equip2.sql文件从而得到equip2.frm文件和equip2.ibd文件
（第一个案例就是我们用数据恢复出来的数据equip1.ibd，这里之所以用equip1.ibd 是因为怕俩个ibd文件搞混乱）
像第一个情况我们就是没有equip1.ibd的frm表结构文件 所以运行不了 现在这个表的表结构拿到了 我们就可以拿之前恢复出来的equip1.ibd数据文件跟这个equip2.frm文件利用数据库运行得到equip整合.sql文件 在使用EmEditor进行解析把之前打包的equip整合.sql 找到客户最新生产的数据 把equip1.ibd-equip2.ibd数据不重复 进行整合处理 这样就基本恢复了客户所需要的数据
因为这次遇见的用这几个方案就完成了 所以更多的方案暂时没办法尝试
后续遇见更多问题 所采方案都会写成成长过程到这里 今天基本上就是把前几天遇见的案例并且做了的进行记录或者可以说加深印象
阅读(310) | 评论(0) | 转发(0) |
