即便采用了定时备份，云盘同步，甚至GIT，却还总是不及随手的一个rm来的杀伤力大。
今天又又又遇到了这个问题，rm随手把刚刚写好的一个cpp文件给删了，一瞬间脚都软了，上周写了一周的ROP，劳民伤财且洋洋洒洒几百行。
Linux下有很多文件恢复类的软件，前序操作一般是umount磁盘，再备份磁盘，最后用这些软件扫描分区，找到误删文件。
只不过现在遇到的情况有点特别，ext4格式的磁盘位于虚拟机当中，整个分区差不多200G，编译Android代码用的。光找个空闲磁盘存放这么大的分区就足够苦恼了，如果还要对这么大的磁盘进行磁盘恢复，时间肯定久到不敢想。
毕竟这个cpp我还是定期备份的，相比之前备份的版本，只是增加了几百行代码而已，现在只要能找到增加的这几行，哪怕有些错乱，理论上再调整下格式就可以了，并不需要传统的文件恢复工具重磅来访。
首先，在分区中搜索新增文字片段中的关键字，关键字要稍微长一点避免重复，比如我的例子中:
fgrep -a -b 'memcpy(mem + 0xA000' /dev/sda3 fgrep: 搜索字符串为文本，而不是正则表达式，会比grep快很多 -a: 搜索时把目标文件当做文本而不是二进制，否则只会输出Binary File Matched字样，而不打印结果 -b: 搜索结果会显示目标字符串所在的文件偏移
通过上面的搜索，可以很快（十分钟以内）找到目标字符串所属偏移（好几组）。
接下来只要从目标分区取回文件内容片段：
dd if=/dev/sda3 of=text.save bs=1 skip=offset_from_fgrep count=8000 skip: 调到fgrep所指的文件偏移附近开始转储文件内容
到此，基本上text.save里存着的就是你的文件内容了，毕竟fgrep时输出的偏移好几组，dd时倒是可以换几个试试，看哪个输出的结果最好。