可靠的文件複製(移動)過程 - 主要是 Unix/Linux
簡短的故事:我們需要一個堅如磐石的可靠文件移動器過程。我們有經常被寫入的源目錄,我們需要從中移動文件。這些文件成對出現——一個大的二進製文件和一個小的 XML 索引。我們得到一個定義這些文件包的 CTL 文件。一旦文件位於目標目錄中,就會有一個程序對文件進行操作;完成後擺脫它們。rsync 會做得最好,還是我們需要變得更複雜?長話短說如下:
我們有多個來源可供提取:一組目錄位於 Windows 機器上(確實有 Cygwin 和 SSH 守護程序),而一大堆目錄位於一組 SFTP 伺服器上(其中大多數也是 Windows。)我們的目標是 AIX 伺服器上的目錄列表。
我們曾經在 Windows/Cygwin 機器上使用非常可靠的 Perl 腳本,因為它是我們唯一的來源。但是,我們正在努力擺脫那台機器,現在還有其他來源,即 SFTP 伺服器,我們目前無法在其上執行我們自己的腳本。
出於安全原因,我們不能在我們的 AIX 伺服器上執行複製作業——它們無權訪問源伺服器。我們目前在 Linux 機器上有一個本地 Java 程序,它使用 SFTP 從各種新的 SFTP 源目錄中提取,複製到本地 tmp 目錄,驗證所有內容都存在,然後將其複製到 AIX 機器,然後刪除文件從源頭上。但是,我們發現了許多錯誤或處理不當的錯誤檢查。我們都不是 Java 專家,因此修復/改進這一點可能很困難。
我們擔心的是:
- 使用遠端源(SFTP),rsync 會留下任何仍在寫入的文件嗎?其中一些文件很大。
- 通過閱讀文件,似乎 rysnc 在可靠地寫入目標之前不刪除源非常好。有沒有人有經驗證實或反駁這一點?
- 附加資訊我們將關注在文件位於目標目錄後對其進行操作的攝取過程。我們不希望它在我們複製文件的過程中對文件進行操作;它一直等到小 XML 索引文件出現。我們目前的複製作業應該最後複製 XML 文件。
- 有時網路會出現問題,有時 SFTP 源伺服器會對我們造成困擾。有時我們打錯配置文件並且目標目錄不存在。我們永遠不想因為這種錯誤而失去文件。
- 我們需要好的日誌
如果你看到這個,你會編寫一些 rsync 腳本嗎?或者你會建構或購買一個工具,如果是的話,它會是什麼(或者它會使用什麼技術?)我(和我團隊中的其他人)對 Perl 很滿意。
編輯: Rsync 進行端到端檢查:文件傳輸後,它會計算目標上該文件的校驗和,並將其與源上的校驗和進行比較。當校驗和匹配時,才聲明傳輸成功。這反映在最終的退出狀態程式碼中 - 如果所有傳輸的文件都通過了測試,那麼退出程式碼將為 0(成功)。
在類似的設置中,我編寫了自己的基於 rsync 的解決方案。它用於夜間備份,我們不會自動刪除文件。
為了解決您的一些擔憂:
- Rsync 從不修改源端的任何內容(除非您使用該
--remove-source-files
選項)。- 如果網路長時間宕機,Rsync 會放棄並給出適當的退出狀態。我在我的腳本和特定的退出程式碼中檢查了這一點(我在實踐中通過記錄觀察到)我讓腳本重試 rsync 命令最多 3 次。
- 是的,您的腳本應該盡可能多地記錄。時間戳、總執行時間、Rsync 存在狀態、Rsync –stats 輸出(傳輸量)。我還在
find
傳輸結束時執行以計算文件數量並du *
獲取目錄大小並記錄下來。基本上你需要處理腳本中的一些事情。主要是:收集退出狀態,一些統計資訊,並在成功傳輸時刪除源文件。
您可以相信 rsync 的退出狀態,即所有請求的文件都已傳輸,但您應該考慮在多大程度上相信您的腳本能夠在源電腦上刪除它們之前為 rsync 提供正確的文件(源目錄)。在您的腳本自動刪除文件之前,可能先計算
find
源文件然後計算目標文件(然後檢查這些數字是否匹配)將是一個很好的最終檢查。給它 10 到 20 次嘗試來開發和測試你的腳本。您需要在 Windows 機器上安裝帶有 rsync 和 ssh 客戶端的 Cygwin。
通過確切地了解它的工作原理,對這樣的應用程序充滿信心是件好事。我從來沒有使用過商業備份軟體——但如果你能找到一個堅如磐石的軟體並信任它——那就去做吧——它可以為你節省很多時間。