服務器每周會產生一次全局備份文件,大小約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占用較多——對於文件系統的操作,簡單增加並發數並不總能提升操作速度。