我写了一个简单的bash脚本来每天备份某些文件到备份挂载，并保留最近3天的备份。 这显然太简单了，因为偶尔会有一些奇怪的行为，这可以通过在公司完成之前执行第一个MV来解释。
这是脚本：
#!/bin/bash mount /mnt/backups while [ ! -d /mnt/backups/dailyBackup-0 ] do echo "Backup mount not present, sleeping..." sleep 30 done rm -r /mnt/backups/dailyBackup-2 mv /mnt/backups/dailyBackup-1 /mnt/backups/dailyBackup-2 mv /mnt/backups/dailyBackup-0 /mnt/backups/dailyBackup-1 dirname="/mnt/backups/dailyBackup-0" mkdir $dirname cd / rsync -qr --stats root etc var $dirname umount /mnt/backups 虽然这很好，但有时候我最终还是会遇到以下情况，看起来像dailyBackup-1在dailyBackup-2被删除之前正在被移动。 如果发生了什么事，防止它的最好方法是什么？
/mnt/backups/dailyBackup-0: total 0 drwxrwxrwx 1 root root 0 2010-12-07 03:27 var drwxrwxrwx 1 root root 0 2010-12-07 02:39 root drwxrwxrwx 1 root root 0 2010-12-07 02:38 etc /mnt/backups/dailyBackup-1: total 0 drwxrwxrwx 1 root root 0 2010-12-06 03:26 var drwxrwxrwx 1 root root 0 2010-12-06 02:32 root drwxrwxrwx 1 root root 0 2010-12-06 02:32 etc /mnt/backups/dailyBackup-2: total 0 drwxrwxrwx 1 root root 0 2010-12-07 02:36 var drwxrwxrwx 1 root root 0 2010-12-05 03:21 dailyBackup-1
问题很可能是RM 失败 ，请注意var在dailyBackup-2中仍然存在，很可能是因为某些文件不能被删除。
作为关于编写系统pipe理shell脚本的一般注意事项：
a）一定要检查脚本的（错误）输出，除非您的电子邮件设置被破坏，您将通过cronjobs的邮件自动接收
b）确保处理所有可能发生的错误（例如，rm或mv失败），将set -e放在脚本之上是一个好主意，这会使shell在遇到第一个未处理的内容时退出错误（对于debugging，还需要添加set -x，这将打印所有正在执行的命令，以便您可以查看脚本正在执行的操作）
并回答您的原始问题：在删除所有文件之前，rm永远不会退出，或者在unlink（）系统调用最后一个文件完成之前更正确地退出。 （唯一的情况下，我可以想象，文件可能仍然存在后，可能是一些模糊的越野车networking文件系统…）但rm退出并不意味着所有的文件被成功删除（即使你是根，并使用-fr（你甚至不使用-f）），例如，如果文件在ext *文件系统上被标记为不可变，或者文件是在rm遍历树时新创build的。 RM会报告一个错误信息和不成功的返回统计tho'
尝试改变这一点
rm -r /mnt/backups/dailyBackup-2 mv /mnt/backups/dailyBackup-1 /mnt/backups/dailyBackup-2 mv /mnt/backups/dailyBackup-0 /mnt/backups/dailyBackup-1
如
rm -r /mnt/backups/dailyBackup-2 && mv /mnt/backups/dailyBackup-1 /mnt/backups/dailyBackup-2 && mv /mnt/backups/dailyBackup-0 /mnt/backups/dailyBackup-1 &&
所以每个命令只有在前一个命令成功完成（换句话说，退出状态为0）时才会运行。
另一台服务器上的文件是否通过NFS挂载访问？ 如果使用软安装设置NFS，则不保证操作将完成。