蚂蚁小窝

昨天再次犯晕，在处理PDC（主域控制器）问题时，一个rm -f smbpasswd.07*,再一看smbpasswd文件大小为0,立即呆了：最新的备份文件几十个全部被删除了，而留下来的最新的是2006.9.9的备份。
       后果很严重，意味着2个机房140多台机器，近2000个学生帐号都无法使用。唯一的办法是恢复最近的smbpasswd文件。而当前smbpasswd文件之所以大小为0，是因为该分区磁盘使用率为100%，没有可用空间了。
    google,baidu了一番，#debugfs, lsdel却未发现被删除的文件。
   原来debugfs之类的工具只能恢复ext2文件系统下被删除的文件，而对ext3无效！
   再google　ext3 文件恢复，却被告知，ext3设计就是无法恢复被删除的文件，文件一删除，其所占目录部分立即被清零。
   唯一的希望是grep!
  问题机器是Fedora core 3操作系统，全部是ext3分区。
 以Fedora Core 6的应急启动盘，启动机器，umount所发现的主分区。因为丢失的文件在根分区，remount readonly未成功。
 查看/etc/passwd文件，最后一个用户是yjzhang6，因此有效的smbpasswd文件最后一个用户也应该是yjzhang6.
 egrep -A0  -B45000 'yjzhang6'   /dev/sda1
这个命令的参数熟悉有点费劲，网上的命令格式根本无法执行，grep在此格式下，把/dev/sda当成了一个文件。所以如果egrep  -l 'yjzhang6' /dev/sda1 返回的是/dev/sda1。我的一些缩小查找范围的实验都失败了。
这条命令是说，在整个/dev/sda1分区搜'yjzhang6'，并且打印‘yjzhang6'所在行的前面的4500行，以及后面的0行。
搜了几分钟，屏幕上出现了我期望的smbpasswd数据！
 再 egrep -A0  -B45000 'yjzhang6'   /dev/sda1 > /tmp/x
 将搜索结果定向到 /tmp/x文件。
 粗略地估算了一下时间，大约10分钟，就结束了命令的运行。再vi /tmp/x文件，果然发现了我需要恢复的文件主体内容，当然更多的是无效的数据，用vi裁减一番，对照/etc/passwd,以及06.9.9的smbpasswd，得出了新的smbpasswd。
 检查空间被用尽的原因，发现是使用domain admin帐号在140台工作站上，用某款杀毒软件的u盘版时，该软件1.8G的备份文件耗尽了根分区空间。
删除之后，重新启动samba 3，问题完全解决。

         猪年如猪！做了这些年网管，一直比较小心谨慎，但今年三月份，连续犯晕。
        教训：现在的服务器都用的是ext3分区，rm -rf误操作的后果是可怕的，rm -f 也要三思而行，尽量以mv代rm。mv 到trash里面，隔断时间再清理trash文件夹。
       smbpasswd文件的备份机制是，每天8－22点，每5分钟，根据学生帐号使用以及充值情况，以程序操作smbpasswd文件，以封禁或者解开学生帐号，如果该文件有变动，则修改前先备份smbpasswd，备份格式为smbpasswd.0703171505之类。
        此文件有8个左右的有效备份文件，幸好其中有一,二个文件在磁盘是连续存贮的，文件也很小，只有5000多行，因此还能够基本完整地恢复数据。如果是单个备份，文件稍大，完整恢复的可能性就不大了。而如果是rm -rf，删除了一个目录，基本上没有完整恢复的希望。