| Linux ext4 rm 误删，用extundelete恢复失败/报错，无数血泪教训！！！附：ext4误删后的正确处理步骤 | 您所在的位置：网站首页 › ubuntu删除的文件怎么恢复 › Linux ext4 rm 误删，用extundelete恢复失败/报错，无数血泪教训！！！附：ext4误删后的正确处理步骤 |
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、云主机运行在云端，传统数据恢复人员缺乏云运维经验，无法快速实施强有力的恢复方案，贻误数据恢复的最后时机 正确的数据恢复步骤 立即启动云主机保护方案，防止数据被继续破坏建立云恢复环境执行专业数据恢复方案导入恢复数据，重建业务在业务确认恢复之前，避免读写模式调用原始磁盘 对于误删后立即关机的云主机，在专业云数据恢复工程师的协助下，有99.99%概率恢复所有数据！ 对于已经有一些文件写入，journal被覆盖的情况，用专业数据恢复方案，仍可抢救大部分重要数据！ 恢复实例教学Linux系统下，用户误删除DB2数据库，自行尝试失败后，联系数据修复工作室支持，以下恢复过程：
用户在/dev/sda划分两个区，/dev/sda2划分为三个lv，最后一个lv格式化为ext4，挂载在/home目录，所有数据已删除，并且用户安装了多个免费数据恢复软件，但均无法恢复数据：
我们立即给出紧急数据保护方案，预计4小时可恢复数据：
分析误删除对EXT4文件系统造成的破坏情况后，我们对关键目录的inode进行了重建。过程略去，相关原理请参考数据修复工作室另一篇原理解析： 《Linux ext4文件系统原理-文件系统结构及文件解析 》，然后用专业软件再进行扫描：
数据修复工作室在14:54恢复出所有数据，仅耗时1小时40分钟：
恢复出目录结构如下：
数据恢复到本地目录下：
协助用户将恢复出的数据导入后，DB2正常运行，恢复圆满结束。 工作室部分恢复案例
Linux主机上的rm误删、上传覆盖，是最危险的。主要是用户抱有侥幸心理，没有果然采取保护措施，甚至尝试安装恢复工具，造成二次破坏。 而对于云主机，传统数据恢复方案不再起作用，您需要有丰富云运维经验+Linux数据恢复经验的复合工程师，给出专业恢复方案！ 本案例中，难点是云恢复方案设计，和ext4文件系统inode重建。 技术支持温馨提示：如重要数据丢失，建议在行动前咨询专业工程师，以免数据遭到二次破坏。 直接技术支持：shop396558956.taobao.com 官方网站：http://www.dataunit.cn/ |
【本文地址】
| 今日新闻 |
| 推荐新闻 |
| 专题文章 |