shell 作为一门 linux 下使用广泛的系统语言，语法简单，上手容易，但是想要用好，少犯错误，也不是那么容易的一件事，可谓虽是居家旅行之良药，但也是杀人灭口之利器~

今天就来聊聊 linux 下一个常见的问题：如何避免误删目录。下文会详细的讲述不同的场景下误删目录，以及相应的解决方案。

1、变量为空导致误删文件 base_path=/usr/sbin tmp_file=cmd_invalid

rm -rf $base_path/$tmp_file

这种情况下如果 cmd 执行出错或者返回为空，后果将是灾难性的，那如何防范呢？ （1）利用 shell 的变量扩展功能，如果变量为空赋给默认值或者抛出异常退出脚本： echo ${base_path:?var is empty}/${tmp_file:?var is empty} -bash: tmp_file: var is empty （2）人肉判断变量是否为空： [[ ${tmp_file} == "" ]] && echo 1 1[[ -z ${tmp_file} ]] && echo 1
1

（3）如果变量未定义还可以开启 set 选项：

cat a.sh

set -u b= echo $b echo $a echo 1

bash a.sh

a.sh: line 4: a: unbound variable 2、路径含有空格导致误删文件 史上最经典的要数下面这个bumblebee项目了，这个项目本来不出名，不过，程序在其安装脚本install.sh里的一个bug让这个项目一下子成了全世界最瞩目的项目。

那我们该如何防范这种问题呢？ （1）良好的编程习惯：变量加引号防止扩展 path="/usr/local /sbin"

rm -rf $path

rm -rf "$path" （2）对变量进行语义检查 比如检测是否含有空格等特殊字符，不通用，不推荐这么做 3、目录或文件含有特殊字符导致误删文件

ll 总用量 8 drwxrwxr-x 2 work work 4096 11月 24 18:57 '~' -rw-rw-r-- 1 work work 34 11月 24 19:49 a.sh

rm -rf ~

那我们该如何防范这种问题呢？ （1）良好的编程习惯：变量加引号防止扩展 rm -rf "~" （2）如果不确定，删除之前 echo 或 find 一下，看变量被扩展成啥了 echo rm -rf "~" rm -rf ~ echo rm -rf ~ rm -rf /home/work 4、cd 切换目录失败，导致文件被误删 cd ooxx_path_not_exsit rm -rf *.exe 恭喜这种情况下你的当前目录下匹配文件都会被误删，那我们该如何防范这种问题呢？ （1）使用逻辑短路操作 cd path && rm -rf *.exe （2）检测 path 是否存在 [[ -d ~ ]] && echo 1 1 5、终极解决方案

不要使用 root 操作系统资源，这样至少不会删除系统文件。 6、在登录 shell 下使用友好的提示符 友好的命令提示符能时刻提醒操作者当前在哪个路径下，避免错误的路径下操作文件。

上文到此就结束了，列举了一些常见的case和解决方案，希望能对大家有所启发。

最后我们来说说删库跑路的事儿：

IT界的一个老梗，一次某论坛的数据库管理员抱怨自己老板一直虐待他，结果他一气之下就删库跑路了……于是就有了从删库到跑路这个梗......

当删库成为一种时尚 6月初，位于荷兰海牙的一家云主机商 verelox.com， 一名前任管理员删光了该公司所有客户的数据，并且擦除了大多数服务器上面的内容，带来了巨大的损失。

2017-04-05，位于纽约的云服务商 Digital Ocean 遭遇了一次长达4小时56分钟的停机事故，事故的原因是主数据库被删除了（primary database had been deleted），由于配置错误，本应指向测试环境的任务被指向了生产环境，测试任务包含的环境初始化过程删除了主生产数据库。（不以规矩不成方圆：Digital Ocean也删除了他们的数据库）

2月11日，网络剪报服务商 - Instapaper 遭受了超过31小时的服务中断，声明需要一个星期的数据库恢复时间，然而经过10天的恢复，也仅仅恢复了6个星期的数据。（云服务真的靠谱吗？ AWS 用户中断31小时仅恢复6周数据）

2月1日，除夕刚刚过完，荷兰的一个DBA在数据库复制过程中意外地删除了一个错误的服务器上的目录，删除了一个包含300GB的实时生产数据的文件夹。300G的数据库被删成4.5G，由于没有有效的备份，尝试了所有5个恢复工具都没有完成恢复。在丢失数据并恢复失败后，服务器彻底崩溃。五重备份无一有效，还有哪些 rm -rf 和GitLab类似的忧伤？

1月20日，大约一定是受到川普上任的影响，突如其来的服务器故障影响了一大批炉石玩家，恢复时间长，由于意外断电，导致数据库损坏，不得不通过游戏回档恢复数据库的使用。

而若操作者具有较高级别的权限，数据库面临的灾难则是巨大的。Lucchese前IT主管，在离职的时候收集了IT部门所有职工的用户名和密码然后伪装成一台办公室打印机创建了一个密码账号，并在其办公室内使用该账号进行了一系列的违规操作，给企业带来了严重的损失。Venzor后来被捕，并面临最高达10年的监禁生活以及25万美元的罚款。

在刚刚过去的7月，花旗银行的前员工伦农·雷·布朗，通过非法执行命令，删除了花旗银行的内部网络上10只核心路由器上的配置文件。结果引起的故障导致全国110个分行无法正常使用网络和电话系统，占到花旗银行所有分支机构总数的约90%。

手动删库简直太low，我都是脚本自动删 又不禁想起了Google曾经轰动一时的流水线删库事件，这可是团队作案哟，这么团结真的好吗？（时移世易：遵从既往经验致 1.5PB 数据删除，Google SRE是如何应对的？） 一个 Google Music 用户汇报某些之前播放正常的歌曲现在无法播放了。Google Music 的用户支持团队通知了工程师团队，这个问题被归类为流媒体播放问题进行调查。3 月 7 日，负责调查此事的工程师发现无法播放的歌曲的元数据中缺少了一个针对具体音频数据文件的指针，于是他就修复了这个歌曲的问题。 但是，Google 工程师经常喜欢深究问题，也引以为豪，于是他就继续在系统中查找可能存在的问题，当发现数据完整性损坏的真正原因时，他却差点吓出心脏病:这段数据是被某个保护隐私目的的数据删除流水线所删掉的。Google Music 的这个子系统的设计目标之一就是在尽可能短的时间内删除海量音频数据。

该流水线任务大概误删除了 60 万条音频文件，大概影响了 2.1 万用户.

没有删过库的Linux管理员，不是好的Linux运维工程师！ 做最优秀的Linux运维工程师，从删库开始！

那么，今天你删库了吗？

来自：xrzs的博客 链接：https://my.oschina.net/leejun2005/blog/793916