故障存储:

存储容量:3.63TB/文件系统:ext4/块大小:4KB

故障现象:

客户描述在一次整理文件时使用“rm”命令（Liunx下删除命令）删除时搞错了目录，导致两个项目中大量的python代码源文件被误删除。出现问题后停止了一切操作，并使用“umount”卸载了问题磁盘。

之后尝试过在“只读”模式下用通用型恢复软件进行扫描，但效果很差。

需要恢复被误删除项目中大量的.py和.ipynb文件，这些文件通常容量不会很大，但是数量很多。

故障分析:

通过查看存在的文件，发现目前逻辑盘中只使用大约389.52GB的空间（图1），用户无法提供删除的文件容量占比只是记得那些被误删除的项目两种文件数量肯定在10W+以上。

.py和.ipynb两种文件简介如下:

1、.py

  .py 文件是 Python 最基本的源代码文件格式，用于存储纯文本形式的 Python 代码。它是开发者编写程序的主要场所，包含函数、类、变量定义以及执行逻辑(图2）。

2、.ipynb

   .ipynb 文件是 Jupyter Notebook 的专用格式，它允许用户在一个网页应用中混合编写 Markdown 文本、执行代码、查看输出结果及图表。这种交互式环境特别适合数据科学、教学和快速原型设计（图3）。

图1：使用空间为389.52GB存在大量的剩余空间

图2：py文件

图3：ipynb文件

可以看到py文件是python绝对的“主力军”，全部代码都在此文件中，而ipynb文件应该是python的一种第三方扩展“插件”。分析两种文件文字都为UTF8编码，由于其内容全部为“代码”文字，所以对于存在碎片的情况无法有效的重组（目前能想到的方法只能手工穷举），而考虑到文件较小出现碎片的机率相对低，所以暂时不考虑碎片的情况。

故障处理:

文字类的文件是以“内容”为导向的文件，其不存在什么“文件结构”（也没必要存在），没有文件结构也就没有所谓的“文件头”更不可能有“文件尾”之类的标识，可以说是最难恢复的文件。通过对py和ipynb文件的分析，得出一些相对来讲有一些规律的地方（比如编程语言的保留字等），面临的难题至少有以下几点：

1、定位文件（筛选出需要恢复的py和ipynb)

2、判断文件内容(对于有碎片或者不正常的文件直接剔除）

3、获取文件长度（要求查找到的文件都是正常文件避免二次人工查看）

这3点问题不解决，肯定是无法得到较好的恢复结果的。通过不断对存在文件的查看，并不断收集这些文件的共同点，基本上算是有了一个相应的方案，下一步就是付诸于实践了。

重新写代码过于繁杂，打算把之前写好的恢复程序拿来做一个“基础”那就是---“CHS数据恢复程序Win版”，这个程序纯粹是之前抽空写出来的，也做了调试，后来一直没有机会正式发布，没想到此次恢复还能用到。有了这个程序做基础，就可以重点来调试这两种文件的恢复算法了，经过一周时间的打磨，程序调试完成，对现有的文件进行了测试，效果非常好。下一步就是直接扫描了:-)

STEP1:运行“CHS数据恢复程序Win版”，点击打开加载镜像文件，程序会自动识别Liunx文件系统的起始和结束扇区并自动添加。选择“ext4”逻辑盘，点击右键，扫描。