实时警报通知:微信告警通知的重要性解析
1200
2023-03-18
Linux系统 运行rm -rf * 后文件恢复
首先,需立即将磁盘挂载为只读。 否则其他daemons 都来读写,神仙都恢复不了了。磁盘规划时一定要做功能分区。否则,误删了想恢复也很困难。比如linux安装时不分区整个装/下面,就很麻烦。 /data挂在/dev/sdb1上
[root@hs12 sh]# mount/dev/sdb1 on /data type ext4 (rw)[root@hs12 hadoop]# mount -r -n -o remount /datamount: /data is busy
[root@hs12 sh]# mount/dev/sdb1 on /data type ext4 (rw)[root@hs12 hadoop]# mount -r -n -o remount /datamount: /data is busy
这需看看有哪些进程在用:
[root@hs12 hadoop]# fuser -v -m /data
[root@hs12 hadoop]# fuser -v -m /data
可以看到有很多java和hadoop进程在使用,杀之。
[root@hs12 hadoop]# mount -r -n -o remount /data
[root@hs12 hadoop]# mount -r -n -o remount /data
成功。 再到/data里touch文件,报错。
[root@hs12 data]# touch atouch: cannot touch `a’: Read-only file system
[root@hs12 data]# touch atouch: cannot touch `a’: Read-only file system
一下就放轻松了很多。因为改为只读挂载后,可以慢慢恢复,再也不用担心我的文件被覆盖。 使用debugfs 用debugfs查找被删文件的inode,再想法恢复。
[root@hs12 ~]# debugfs /dev/sdb1debugfs 1.41.12 (17-May-2010)debugfs:debugfs: lsdelInode Owner Mode Size Blocks Time deleted0 deleted inodes found.
[root@hs12 ~]# debugfs /dev/sdb1debugfs 1.41.12 (17-May-2010)debugfs:debugfs: lsdelInode Owner Mode Size Blocks Time deleted0 deleted inodes found.
神奇的debugfs 根本没找到有文件被删除的inodes,难道是我不会用? 失败! 使用grep恢复 grep 在磁盘二进制中查找文本,把前后的字符导出来,也许可以恢复部分。
[root@hs12 hadoop]# grep -a -B 100 -A 100 ‘active.sh’ /dev/sdb1 > results.txt
[root@hs12 hadoop]# grep -a -B 100 -A 100 ‘active.sh’ /dev/sdb1 > results.txt
只有一些乱七八糟的二进制。失败!使用ext3grep 我的是ext4系统,根本不起作用。 只好寻找专业工具 用testdisk 6.14
使用介绍:
下载:
1 2
发表评论
暂时没有评论,来抢沙发吧~