[数据恢复故障描述]

一台重💲要的🕛MYSQL数据库🎇服务器，146GB*2，RAID1，约【yuē】🚝130GB DATA卷【juàn】，存储了🛫大约【dà yuē】🚝200~300个数据【gè shù jù】库🎇。平时管【píng shí guǎn】理员对每个数🛢据库dump出以后【chū yǐ hòu】⛎，直接压缩成【suō chéng】.gz包，再将所【zài jiāng suǒ】有重要的🕛.gz 包合起来压缩🤰成一个📔总的🎻.tar.gz包，这些文【zhè xiē wén】件每日产生一次，覆盖原【fù gài yuán】来的备【lái de bèi】份。数据文件及备🕠份文件【fèn wén jiàn】全部存储于🏐data卷【juàn】上。

一次系【yī cì xì】🌂统维护中【zhōng】，管理员【guǎn lǐ yuán】不小心将🦋data卷下的【juàn xià de】所有文【suǒ yǒu wén】件全部rm，删除后【shān chú hòu】😅，马上停🚸止系统，再未做【zài wèi zuò】其它操作🍱，但删除🏰时仍有大量终端在访问此服务器🥒。

要求恢复🍖mysql数据库【shù jù kù】文件😋，即📑myd、frm、myi(可重建)文件😋，或每个数据库【shù jù kù】的【de】.gz包【bāo】，或所有🍵重要数据库【shù jù kù】总的【de】.tar.gz备份包【bèi fèn bāo】🍞。

[数据恢复分析]

ext3下的数【xià de shù】据删除，理论上，会清【huì qīng】📕除inode中除节点类型🈺、日期外的其他【de qí tā】😰属性【shǔ xìng】，诸如文【zhū rú wén】件🏷大小【dà xiǎo】、数据存储地址【chǔ dì zhǐ】等属性【shǔ xìng】会全部清📕0，同时目录表中会以目录条目🤩长度的【zhǎng dù de】方式屏蔽掉已删除文👢件🏷，但会保留节点🙃编号【biān hào】🔘，最后会【zuì hòu huì】改变💯BITMAP中的空间占用【jiān zhàn yòng】标志😑。

即使是目录表😕中存在删除文件的节【jiàn de jiē】🧝点编号，但因节🧡点内容【diǎn nèi róng】💢已经没【yǐ jīng méi】有需要【yǒu xū yào】的东西，与数据区也是👕脱钩的【tuō gōu de】。

从数据【cóng shù jù】🚍角度🥦，大多数文件类【wén jiàn lèi】🙀型都会有特定【yǒu tè dìng】的文件头标志【zhì】🎏，按头标志【zhì】🎏是有可能找到【néng zhǎo dào】删除文件的起始位置的，但🕉EXT3以块组【yǐ kuài zǔ】🅰为单位🏽进行存【jìn háng cún】储【chǔ】，同时数据与索😙引是混合存储【chǔ】💘于数据区的【qū de】，所以数据连续🍍存储【chǔ】的可能性🔹非常之【fēi cháng zhī】小🐊，这样【zhè yàng】，按文件格式进行处理也是很困难的【kùn nán de】。

唯一的【wéi yī de】🛤算法是结合上述几个♏特征🌞，加上对【jiā shàng duì】日志的分析🖤，加上对【jiā shàng duì】存储过🚧程的模拟分析🖤，尽可能地逼近真实存【zhēn shí cún】储结构【chǔ jié gòu】。

[数据恢复过程]

1、对故障卷做完整备份。

2、对总👑.tar.gz进行恢🏵复分析，但恢复【dàn huī fù】出来的【chū lái de】文件解🚊压到【yā dào】50%左右会报错，后续文件列表🦇也无法列出【liè chū】。经分析，最大的原因是删除时【shān chú shí】😿仍有数【réng yǒu shù】据写入【jù xiě rù】破坏文💟件导致✏。

3、对分包的【de】.gz文件进🎺行恢复分析，大多数🏰恢复成【huī fù chéng】🌕功【gōng】。

4、对于未🍠恢复成【huī fù chéng】功🐾的.gz数据库。直接恢复其myd\frm数据文【shù jù wén】件【jiàn】，所有数据恢复【jù huī fù】🤣成功🐾。

[其他]

1、LINUX EXT3数据删【shù jù shān】除后应🍱尽快断【jìn kuài duàn】❓掉文件👜系统IO，通常umount文件系统即可【tǒng jí kě】。

2、对故障🉐卷做🌧dd备份，确保数🔔据恢复【jù huī fù】过程不会导致【huì dǎo zhì】更严重【gèng yán chóng】的故障。