如何预防程序员rm -rf /* 删库跑路

1.前言

网上曾经出现过一个段子,某程序员对老板说“你不要逼我,把我逼急了我rm -rf / * ,就算技术总监也别想恢复”。rm 操作真的无法恢复么?重要的文件该怎么设置才能让rm操作失效呢?

2.Ext文件系统

简单来说,Ext文件系统会将文件的权限和属性、实际数据分别存放在inode和data block中,另外还有一个superblock会记录整个文件系统的整体信息。

inode:记录文件属性,一个文件对应一个inode,每个inode将指向数据存放的block地址

block:实际文件内容,超出block大小会占用多个block

3.日志文件系统(Journaling file system)

Ext3开始,系统支持了日志文件。每次系统写入文件的时候,会先在日志记录某个文件需要写入的信息,写入时更新meta data数据,结束后,在日志中更新该文件记录。

4.日志文件系统模式

1.writeback(写回)

对文件系统元数据发生改变时才会记录日志,这种模式效率最快。

2.orderd(预定)

对文件系统元数据发生改变时才会记录日志 ,文件系统会把元数据和相关的数据块进行分组,在写入磁盘前写入数据块。

3.journal(日志)

只要文件系统的所有数据和元数据改变时就记入日志,这是最安全的模式,性能也是最慢的。

4.设置系统模式

通过挂载分区时 设置: mount /dev/vda1 -o data={模式}

5.文件系统的恢复

当我们进行rm操作之后,文件的操作会被日志记录,而rm的操作只是将inode执行block的指针删除,而并没有把block块中的数据删除。所以理论上利用日志可以查找到block块的地址,然后通过dd把内容拷贝出来进行恢复。那么如何手动进行恢复呢?

1.如果不知道文件的inode号,可以先通过 debugfs /文件分区 以默认读方式打开分区

2. debugfs ls -d /path 找到删除目录下的 被删文件 一般删除后会显示<num>,这个num就是inode号

3.debugfs logdump -i <num> 找到inode块对应的block号码。(这里注意logdump只支持ext3的日志读取)

4.dd -if=/文件分区 -of=/path/restore.file bs=4096 skip=block号码 count=1 进行恢复

上面的做法是网上普遍有的,但是本人亲自实验了一下最后以失败告终。

5.第三方恢复软件extundeleted 通过yum -y install extundeleted就可以便捷安装

执行extundeleted /分区 –restore-all 可以将所有该分区下被认为是删除的inode进行恢复。(注意,执行该命令的时候确保不在需要恢复的分区下)

本人亲自实验:只能恢复部分小文件,对于大文件依然没用,只能恢复少数字节。既然恢复这么困难,我们只能从如何预防出发了。

6.文件删除的预防

6.1 文件属性入手

对于文件的删除,文件的某些属性可以做到误删的预防。

我们的救星就是 chattr ,它对不同文件系统的支持也是不同的。

chattr +i /file 可以将文件设置为不可读、写、移动等。这条命令能有效的保障文件的绝对安全。但是我们的生产环境,后台程序需要IO操作,所以这条命令只适用于不需要IO操作的文件。

6.2障眼法

通过对rm设置别名,将rm操作转化为mv操作,然后再跑一个计划任务,每次定时删除被mv操作处理的的文件。

alias rm=trash
trash()
{
  if [ ! -z $2 ]
  then
  mv $2 /trash
  else
  mv $1 /trash
  fi
}

6.3权限分配,避免程序员获得较高权限的账户

7.感想

删库跑路,不利己不利他。如果要规避,那么站在公司角度,不要让程序员受委屈(该涨薪就涨薪)。站在程序员角度,提示自我修养。

8.后续补充

通过设置目录的特殊权限可以避免其他用户删除目录,就算目录是777权限

方法:chmod o+t 目录名

补充时间:2020-04-18

详见Linux文件权限手札
如无特殊说明,文章均为本站原创,转载请注明出处。如发现有什么不对的地方,希望得到您的指点。

发表评论

电子邮件地址不会被公开。 必填项已用*标注