問題:
某台機器的備份指令碼不能定期執行
,具體表現為備份指令碼執行一段時間之後
,備份目錄
/home/dbbackup
被刪除,
導致備份無法正常完成
基本情況:
機器無被入侵跡象
備份指令碼共有兩個
:a-bck.sh
和b-bck.sh
分別對專案a和
b的資料進行備份
,分別在0點和
1點執行
其中a-bck.sh
是我之前所寫
,已經執行了很長時間沒有問題
b-bck.sh
是同事最近所寫
,在執行了一段時間之後出現這樣的問題
指令碼說明:
1.指令碼
a-bck.sh
的內容是將
a專案的備份都放在
/home/dbbackup/下
定期刪除
7天之前的檔案
,刪除命令寫的是
find /home/dbbackup/ -mtime +7 |xargs rm -r
2.後來同事為
b專案寫備份指令碼
b-bck.sh,
內容參照我的原指令碼
為了區分專案,他將
a和b兩個專案的備份分開放在
/home/dbbackup/a/
和/home/dbbackup/b/下,
並按此修改了我的備份指令碼
a-bck.sh
中的備份路徑
但是指令碼裡面的定期刪除命令並沒改
,仍然是
find /home/dbbackup/ -mtime +7 |xargs rm -r
問題原因分析:
每次指令碼執行
,備份檔案都是產生在"/home/dbbackup/專案目錄/"下
系統裡面標識有改動的就是
"檔案"
和"/home/dbbackup/專案目錄"(
通過ll
命令檢視改動日期這兩個的修改時間會變化
),系統認為"/home/dbbackup"
目錄並沒有改動
(ll命令顯示此目錄的改動日期不變)
所以當同事將專案分了目錄的
7天過後
,指令碼執行
find /home/dbbackup/ -mtime +7
出來的結果含有
"/home/dbbackup/",
所以此目錄就被刪除語句給直接刪掉了
解決辦法:
將刪除語句改為
find /home/dbbackup/a/*.* -mtime +7 |xargs rm –r
find /home/dbbackup/b/*.* -mtime +7 |xargs rm -r
即將find
細化到專案檔案下
,這樣就保證搜尋出來的都是特定目錄下的檔案了
原理:
乙個多級目錄
/a/b/c/ ,如果c
下產生,修改,
新建,刪除檔案或者目錄
,那麼修改時間
(1l命令顯示的時間
)會變化的是c,
上級目錄a和
b的修改時間並不會改變
舉例: 假設
10天前
,建好目錄結構
/a/b/c/,
並設定好備份任務,在
c目錄下每天產生備份檔案
,名稱為
1,2,3
依次累加
,到今天產生到檔案10
那麼使用
find /a/b/ -mtime +7
查詢修改時間在
7天之前的檔案
,結果為
/a/b/(
其修改時間是
10 天前
, 也在查詢的範圍內)
1,2,3(
這是7 天前產生的檔案)
注意c不在
,因為每天產生乙個備份檔案
,c的修改時間隨之更新
要達到只刪除檔案的目的
,就需要具體到目錄
find /a/b/c/ -mtime +7
或者更加明確到檔案
find /a/b/c/* -mtime +7
教訓:
每次修改指令碼的時候
,必須測試.
這次就是因為同事在修改我指令碼的時候
,並沒有測試我的指令碼
.(因為我的指令碼一直執行正常
,他只是修改了乙個目錄而已
,大意的認為沒有問題)
由搜狐案例所想到的
4月29 日下午，我應邀參加 網際網路實驗室 舉辦的 智財權過度保護與中國網際網路發展研討會 很有感觸。會議討論了網際網路 搜尋引擎 運營商的法律責任問題。在網際網路時代，搜尋引擎 一定會助長 網路盜版 現象。網路盜版的氾濫，搜尋引擎 運營商總歸逃脫不了受到 牽連 命運。近年來，對於智力作品的作者賦...
原創 由分水所想到的
今天和週三石在討論乙個問題的計算機解法的時候，突然對倒水的這個問題有了比較穩妥的乙個演算法，也不枉費我一番苦心。問題場景 現有一10l的桶子x 裝滿水 然後有y桶和z桶，分別是7l和3l的容積 均為空 現在要分出5l，怎麼辦?我們一般遇到這樣的場景的時候會首先不會去分析它的解法，而是在大腦裡面不斷的...
由深圳的大樹所想到的
吾以前的公司在福田區，那裡的大榕樹特別多。跟別人談起的時候，有人說那是老城區，新城區綠化就不行了。吾一想，還真是，新城區的樹確實小。福田區的這個大樹，當然不可能是移植的，是以前就有的。新城區的樹 去了？什麼時間，什麼人？有沒有人考證一下？吾老家寺口，印象中也有大樹。以前的寺口聯中和舊公路橋之間，有兩...