Linux ext4 rm 误删,用extundelete恢复失败/报错,无数血泪教训!!!附:ext4误删后的正确处理步骤

目录

典型误操作

Ext4误删恢复原理

恢复失败的主要原因

正确的数据恢复步骤

恢复实例教学

工作室部分恢复案例

技术支持



典型误操作

阿里云WEB CentOS 云主机,默认为ext4文件系统。用户rm * -rf 误删除MySQL数据库整个目录。

用户下载安装了extundelete等软件,发现可以看到被删除文件,但用恢复时报错。

明明百度上都说extundelete是神器,为什么我们在生产环境,它却很难恢复出重要数据呢?


Ext4恢复原理

文件系统由元数据数据块两部分组成,元数据存放索引信息,数据块存放文件内容。Ext3、ext4还支持journal日志,journal循环记录近期对文件的操作。免费数据恢复软件,通过扫描journal日志恢复数据。

但是journal日志通常比较小,新的IO操作很快会覆盖老的记录。如下图所示,journal仅8192 block:


恢复失败的原因

若想尝试,务必先做快照!!!

若想尝试,务必先做快照!!!

若想尝试,务必先做快照!!!

1、下载/解压/安装各种软件,都在写入大量新文件,造成严重的破坏。

注意:网上的extundelete恢复案例,仅在简单的实验环境,rm删除几个文件,并且立即恢复,造成extundelete的恢复能力很强的假象。但在繁忙的业务系统,误删后再安装extundelete造成大量新文件写入,再恢复的概率极低。若要测试,务必先做快照!!!

 

2、rm删除后,没有立即关机,运行的系统在持续覆盖误删数据。

正式业务系统IO繁忙,导致journal很快被占满,使journal恢复失败。

3、云主机运行在云端,传统数据恢复人员缺乏云运维经验,无法快速实施强有力的恢复方案,贻误数据恢复的最后时机



正确的数据恢复步骤

  1. 立即启动云主机保护方案,防止数据被继续破坏
  2. 建立云恢复环境
  3. 执行专业数据恢复方案
  4. 导入恢复数据,重建业务
  5. 在业务确认恢复之前,避免读写模式调用原始磁盘
  • 对于误删后立即关机的云主机,在专业云数据恢复工程师的协助下,有99.99%概率恢复所有数据

  • 对于已经有一些文件写入,journal被覆盖的情况,用专业数据恢复方案,仍可抢救大部分重要数据!


恢复实例教学

Linux系统下,用户误删除DB2数据库,自行尝试失败后,联系数据修复工作室支持,以下恢复过程:

用户在/dev/sda划分两个区,/dev/sda2划分为三个lv,最后一个lv格式化为ext4,挂载在/home目录,所有数据已删除,并且用户安装了多个免费数据恢复软件,但均无法恢复数据:

我们立即给出紧急数据保护方案,预计4小时可恢复数据:

分析误删除对EXT4文件系统造成的破坏情况后,我们对关键目录的inode进行了重建。过程略去,相关原理请参考数据修复工作室另一篇原理解析:

《Linux ext4文件系统原理-文件系统结构及文件解析

,然后用专业软件再进行扫描:

数据修复工作室在14:54恢复出所有数据,仅耗时1小时40分钟:

恢复出目录结构如下:

数据恢复到本地目录下:

协助用户将恢复出的数据导入后,DB2正常运行,恢复圆满结束。


工作室部分恢复案例

部分extundelete失败案例


特别注意

Linux主机上的rm误删、上传覆盖,是最危险的。主要是用户抱有侥幸心理,没有果然采取保护措施,甚至尝试安装恢复工具,造成二次破坏。

而对于云主机,传统数据恢复方案不再起作用,您需要有丰富云运维经验+Linux数据恢复经验的复合工程师,给出专业恢复方案!

本案例中,难点是云恢复方案设计,和ext4文件系统inode重建。


技术支持

温馨提示:如重要数据丢失,建议在行动前咨询专业工程师,以免数据遭到二次破坏。

直接技术支持:shop396558956.taobao.com

官方网站:http://www.data-unit.com/

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页