Linux rm -rf 误删数据恢复

a、epel 仓库安装

如果我们的源里面添加了 epel 仓库的话，我们可以直接使用下面的命令安装。

b、源码编译安装

c、查看安装情况

先从根分区 inode 查找：

比如此处需要继续进入root则：

根据需要找到自己最终删除数据的目录

我们可以看到标称的 Deleted，这些数据就是我们要进行恢复的数据

注意： 有时候恢复数据会报错

此时，多尝试几种恢复方式

指定目录恢复，以当前分区为根分区进行路径设定，项目名进行掩盖

恢复全部数据可以使用命令

根据inode恢复

其他命令自行查看帮助

恢复的数据会在当前目录生成一个目录 RECOVERED_FILES 里面就是我们恢复的数据。

*** 作如图：修改了软链接导致系统大部分命令不能使用 解决方法1：ldconfig -l -v /lib64/libc-2.12.so 解决方法2： libc.so.6被破坏的修复方法： 在每条命令前加上 LD_PRELOAD=/lib64/libc-2.12.so 前缀，不能使用的命令可以重新使用。例如 LD_PRELOAD=/lib64/libc-2.12.so ls，ls命令可以重新使用。删除lib64下被破坏libc.so.6文件，再使用LD_PRELOAD=/lib64/libc-2.12.so ln -s /lib64/libc-2.12.so /lib64/libc.so.6，问题解决。 libc.so.6被删除的修复方法： LD_PRELOAD=/lib64/libc-2.12.so ln -s /lib64/libc-2.12.so /lib64/libc.so.6 ############################################# libc.so.6介绍： libc.so.6是glibc的软链接，glibc是gnu发布的libc库，即c运行库。glibc是linux系统中最底层的api，几乎其它任何运行库都会依赖于glibc，所以说绝大部分 *** 作命令都缺少不了它。如果误删或破坏了libc.so.6，大部分系统命令将无法执行，ssh登录系统也不成功，只会无休止的提示以下错误: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory 这种情况下，大部分命令已经不能执行了，只能执行例如cd,echo等小部分命令，而实用的cp,mv则不可用，如果想解决，记得ssh一定不要断开，如果ssh已断开则无法重新连接上，得使用另外的方法用光盘重启进入急救模式！！！ 在同版本系统上查看/lib/libc.so.6得知是属于libc-2.12.so的软链接，因此，libc-2.12.so文件肯定还是存在的，误删的只是软链接而已，但此时想用ln命令重新建立软链接是失败的，但是可以这样强制设置变量就能执行成功！ LD_PRELOAD=/lib/libc-2.12.so   ln -s /lib/libc-2.12.so /lib/libc.so.6 斜体加粗部分为glibc临时指定的库，这样正确执行后libc.so.6就正确恢复了。 glibc是一个非常底层的库，bash也依赖它，所以，如果把这个库干掉了，基本上啥事都干不了了，但是为啥前面设置一下LD_PRELOAD变量 就可以了呢？是这样的，LD_PRELOAD可以影响程序的运行时的链接（Runtime linker）， 它允许你定义在程序运行前优先加载的动态链接库，之前把libc.so.6这个软连接给干掉了，所以系统找不到这个库了，但是通过LD_PRELOAD设置一下glibc这个库的真实地址就可以解决这个问题了。

拿到了新linux服务器，开心地 *** 作linx，行云流水地搭建了nginx前端代理服务，并在nginx服务中部署前端应用。心里开始有点膨胀，于是就乐极生悲，有了这个蛋疼的 *** 作，将linx系统根目录下的bin文件夹中的内容全部给删除了，（当时脑子短路了有一分多钟，心里直冒冷汗）。

误 *** 作过程： 部署前端应用的流程是，先将nginx应用根目录下html文件夹中已经部署的旧版本删除，在删除前端项目时，因为有历史 *** 作，所有没有仔细看文件夹路径，直接ctrl-A删除了当下目录中的所有文件。（前端应用是angular2项目，build出来的项目，所有有文件都是同一级目录，文件有点多，且每个文件名都是随机生成的）。

使用xftp，需要先将html文件夹中的内容全部删除，因为已经 *** 作过这个步骤，所以想当然的以为打开xftp会默认打开html文件夹。于是在 *** 作过程中，直接将xftp默认打开的文件夹下的所有文件给删除了（默认在bin目录）。删除那一瞬间感觉删除文件不对，查看目录路径，果然错了。

当时所有文件都已经删除了，ctrl+c已经迟了。。。

先了解了一下bin目录下文件内容的作用：bin文件夹下的内容文件为常用的shell命令，在下面的截图中可以看到：cat，chmod，cp，login... 等常用命令。看到login也在里面，感觉有点不妙，会不会是这台服务器已经不能再远程登录了？黑人脸问号.png。

使用ssh测试远程连接，果然连接不上了。于是网上搜索补救措施，看了好多网上教程，好多都是使用ssh连接（在没有关闭ssh连接的前提下 *** 作），远程恢复的。网络上的恢复教程大致是： 从其他的相同的linux *** 作系统中复制一份bin文件到已经删除的linux系统中。 但远程ssh登录不了，复制不了文件到这个linux系统中。但是想到有xftp还没有关闭连接，于是就打算采用这个xftp恢复bin目录。

使用虚拟机软件，创建一台相同liunx版本的系统，再将系统中bin文件夹中的内容复制一份。并使用xftp将bin文件内容复制到删除的目录中。

重新测试ssh远程登录连接系统，结果还是不行。继续思考为什么会不行。想到会不会是文件权限引起的问题，还好xftp可以查看文件权限，果然有这个问题，xftp复制进系统的文件权限只有只读权限，可bin目录下的文件都是需要执行权限的啊。还好xftp可以修改文件权限，于是有了以下的修改权限的截图。绿色的文件代表可以执行，也就说先将以下的的文件中比较重要的文件（绿色的文件，修改权限前文件为灰色）权限改为755。然后再ssh远程登录系统，果然ok，可以登录且可以 *** 作系统。接下来将bin文件夹中的所有文件权限改为 755，恢复完成。

---