☰

日常備份時 rsync 發生 IO 錯誤

tag-icon • tag-icon rsync linux-kernel
日常備份時 rsync 發生 IO 錯誤

我有一個範例 NAS 伺服器 (QNAP TS-210)，其板載 Linux 非常有限（儘管使用 Optware/IPKG 進行了一些加強）。我是一個 Linux 新手。在深入研究互聯網後，我能夠編寫自己的備份腳本，使用 rsync 在 NAS 硬碟和外部 USB 驅動器之間同步文件，並使用 CRON 定期運行該腳本。

直到幾天前一切都很好。備份腳本產生的電子郵件開始包含IO error encountered -- skipping file deletion許多正在備份的資源（資料夾）的資訊。當我透過 SSH 運行相同的腳本時，我收到很多錯誤行，上面寫著“ cannot send file with empty name in...”，後面跟著“ rsync error: some files/attrs were not transferred (see previous errors)”。

我備份的內容 100% 來自 Windows（我只使用 NAS 備份自己的電腦）。系統不允許建立空名稱的檔案。這個問題只存在幾天，而且我已經有幾個星期（假期）沒有修改我的備份了。所以這一定是 Linux（我的 NAS 上的）問題。

問題是：什麼會導致檔案顯示為空名稱？我怎麼能擺脫它們（當我cd到 rsync 報告中提到的資料夾並執行操作時ls -ls，我看不到任何類似“名稱為空的文件”之類的內容），因此下一個rsync 傳遞最終將不會出現此類錯誤。最後——如何避免將來獲得此類文件？

答案1

我不認為這是 rsync 的錯。我認為您已正確地將其標記為內核級問題，因為相關程式碼來自 rsync 的flist.c來源內容如下：

1729         for (errno = 0, di = readdir(d); di; errno = 0, di = readdir(d)) {
1730                 unsigned name_len;
1731                 char *dname = d_name(di);
...
1746                 if (dname[0] == '\0') {
1747                         io_error |= IOERR_GENERAL;
1748                         rprintf(FERROR_XFER,
1749                                 "cannot send file with empty name in %s\n",
1750                                 full_fname(fbuf));

事實上，這行程式碼是rsync開發者新增的早在2007年8月特別針對這種情況：

If readdir() gives us an empty name, reject it.

換句話說，readdir()它本身（返回目錄中文件列表的內核函數）會傳回一個帶有空白字串的條目。根據規則，這種事永遠不該發生。引用自開放組規格：

The readdir() function shall not return directory entries containing empty names.

聽起來這是某種暫時性問題，因為當您ls在該目錄中執行 an 操作時，它已經消失了（也可以使用readdir()，它已經消失了）。

所以回答你的問題：

  1. 原因似乎是檔案系統損壞 - 從核心驅動程式錯誤到硬體故障都可能是原因。也可能值得檢查您正在同步的目錄是否透過符號連結存取或跨越可能存在問題的網路邊界本身。

  2. 要擺脫它們：通常的檔案系統修復清單：fsck 等。

  3. 為了將來避免：我想你可以告訴你的腳本預先強制遞歸列表 - 但由於你已經引起注意（並且你從假期回來），似乎正確的做法是密切關注如果再次發生這種情況，就跳到盒子上。

希望這有用，祝你好運！

相關內容