服务器每周会产生一次全局备份文件，大小约100G左右，需要定期清理。

　　工作时间网站访问大，服务器I/O高的时候删除大数据会对服务器状态产生不好的影响。

于是想利用计划任务自动执行。

　　在我的备份目录/bakcup下，每次备份文件均以日期形式命名目录名：　　代码如下:　　# ls　　2013-12-23 2014-01-06 2014-01-20 2014-02-03　　2013-12-30 2014-01-13 2014-01-27 2014-02-10　　删除部分备份同时保留部分，可以使用find命令，如我要保留最近四周备份的文件，每次备份间隔七天：　　代码如下:　　# find /bakcup/ -maxdepth 1 -type d -mtime 28　　/bakcup/2014-01-06　　/bakcup/2014-01-13　　/bakcup/2013-12-23　　/bakcup/2013-12-30　　-maxdepth 1：设置查找目录深度为1，只在/backup目录下查找，如不加此参数会将下级目录中的文件都列出　　-type d：设置查找类型为目录　　-mtime 28：查找28天前的目录　　查找结束后可用-exec参数连接删除命令　　代码如下:　　rsync --delete-before -d /data/test/ {} \;　　所以，整个命令就是：　　代码如下:　　# find /bakcup/ -maxdepth 1 -type d -mtime 28 -exec rsync --delete-before -d /data/test/ {} \; p　　最后可以把命令放入脚本，设置crontab自动执行。

　　提醒：　　使用命令前，应先在服务器上试用查找部分的命令，如只查找出要清理的目录，则可以继续。

　　不排除某些系统会将./目录查找出来，一定要看清楚，防止出现意外情况。

　　另外可将-exec替换为-ok，效果相同，在删除前提醒用户确认。

　　PS：rm命令与rsync命令的效率比较　　rm　　rm命令大量调用了lstat64和unlink，可以推测删除每个文件前都从文件系统中做过一次lstat操作。

　　lstat64的次数低于文件总数，还有另外的原因，之后会在另一篇文章中说明。

　　getdirentries64这个调用比较关键。

　　过程：正式删除工作的之一阶段，需要通过getdirentries64调用，分批读取目录(每次大约为4K)，在内存中建立rm的文件列表;第二阶段，lstat64确定所有文件的状态;第三阶段，通过unlink执行实际删除。

这三个阶段都有比较多的系统调用和文件系统操作。

　　rsync　　rsync所做的系统调用很少。

　　没有针对单个文件做lstat和unlink操作。

　　命令执行前期，rsync开启了一片共享内存，通过mmap方式加载目录信息。

　　只做目录同步，不需要针对单个文件做unlink。

　　另外，在其他人的评测里，rm的上下文切换比较多，会造成System CPU占用较多对于文件系统的操作，简单增加并发数并不总能提升操作速度。