目录
恢复实例教学
典型用户故事
阿里云WEB服务器主机，安装CentOS系统，创建ext4文件系统。用户误删除MySQL数据库整个目录，导致网站业务停机。
用户自行下载安装了extundelete等反删除软件，发现可以看到被删除文件的inode，并显示为delete状态，但用恢复时报错无法恢复。
Ext4误删恢复原理
文件系统由MetaData和DataBlock两部分组成，MetaData存放索引消息，superblock，inode分配表，datablock分配表等都可归类为MetaData。DataBlock存放真实数据块。而Ext3、ext4文件系统支持journal日志，journal循环记录近期对文件的操作，在系统意外掉电时，可利用journal修复文件系统。而多数免费数据恢复软件，通过扫描journal日志恢复数据。
但是journal日志通常比较小，新的IO操作很快会覆盖老的记录。如下图所示，journal仅8192 block：
恢复失败的主要原因
1、误删除后，没有立即关机，运行的系统在持续覆盖误删数据。
操作系统只要在运行，就会有IO，而对于业务系统，IO可能更频繁。这导致journal很快被占满，自动循环删除之前的操作记录，并重新分配使用inode，使得通过journal恢复失败。
2、下载、解压、安装extundelete，这些操作都在占用journal。用户尝试恢复文件过程，就是破坏文件的过程。
注意：网上多数extundelete的恢复案例，仅在简单的实验环境，删除了几个文件，并且立即恢复，造成extundelete的恢复能力很强的假象。但在繁忙的业务系统，误删后再安装extundelete，数据恢复的可能性极低。
3、更多的IO写入，将有概率覆盖文件的DataBlock，这表示数据彻底不可能恢复。
4、云主机运行在云端，传统数据恢复人员缺乏云运维经验，无法快速实施强有力的恢复方案，贻误数据恢复的最后时机
正确的数据恢复步骤
- 立即启动云主机保护方案，防止数据被继续破坏
- 建立云恢复环境
- 执行专业数据恢复方案
- 导入恢复数据，重建业务
- 在业务确认恢复之前，避免读写模式调用原始磁盘
- 对于误删后立即关机的云主机，在专业云数据恢复工程师的协助下，有99.99%可能性恢复所有数据。
- 对于已经有大量文件写入，journal被覆盖的情况，用专业数据恢复方案，仍可抢救重要数据。
恢复实例教学
Linux系统下，用户误删除DB2数据库，自行尝试失败后，联系数据修复工作室支持，以下恢复过程：
云数据恢复工程师随后预检，确认用户在/dev/sda划分两个区，/dev/sda2划分为三个lv，最后一个lv格式化为ext4，挂载在/home目录，所有数据已删除，并且用户安装了多个免费数据恢复软件，但均无法恢复数据：
数据修复工作室立即给出紧急数据保护方案，预计4小时可恢复数据：
数据修复工作室立即分析误删除对EXT4文件系统造成的破坏，并对关键目录的inode进行了重建（过程略去，相关原理请参考数据修复工作室另一篇原理解析：Linux ext4文件系统原理-文件系统结构及文件解析 ），然后用专业软件再进行扫描：
数据修复工作室在14:54恢复出所有数据，仅耗时1小时40分钟：
恢复出目录结构如下：
数据恢复到本地目录下：
协助用户将恢复出的数据导入后，DB2正常运行，恢复圆满结束。
工作室部分恢复案例
部分extundelete失败案例
技术支持
温馨提示：如重要数据丢失，还请在行动前咨询专业工程师建议，以免数据遭到二次破坏。