☰

錯誤

tag-icon • tag-icon debian tar corruption
錯誤

如何調試這個？這個問題是這兩天突然出現的。網站的所有備份均已損壞。

如果備份只是保留為tar，則沒有問題，但是一旦 tar 被壓縮為 ，gz否則xz我無法解壓縮它們。

有大量可用磁碟

Local disk space    2.68 TB total / 2.26 TB free / 432.46 GB used

錯誤

tar: Skipping to next header[===============================>                                                    ] 39% ETA 0:01:14
tar: A lone zero block at 2291466===============================>                                                ] 44% ETA 0:01:13
tar: Exiting with failure status due to previous errors
 878MiB 0:00:58 [15.1MiB/s] [===================================>                                                ] 44%

為什麼這麼說Skipping to next header？它以前從未這樣做過。有些文件出了嚴重的問題。

目錄中有大約 15k 個 pdf、jpg 或 png 檔案。

命令

pv $backup_file | tar -izxf - -C $import_dir

一定有一些資料破壞了壓縮。

我還嘗試透過執行以下操作來檢查硬碟的運作狀況：

# getting the drives
lsblk -dpno name

smartctl -H /dev/sda
smartctl -H /dev/sdb

在兩個驅動器上我都得到這個：

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

如何找出哪些檔案損壞了 tar.gz？我只想刪除它們。

更新

現在已將所有檔案複製到另一台伺服器，我遇到了完全相同的問題。我可以壓縮所有內容並毫無問題地提取它，但是一旦我想壓縮文件，我就無法解壓縮它們（gz/xz）。

答案1

您的檔案已被截斷或損壞，因此xz無法到達資料末尾。tar抱怨是因為存檔在中間停止，這是合乎邏輯的，因為xz無法讀取整個資料。

執行以下指令查看問題出在哪裡：

cat /var/www/bak/db/2017-05-20-1200_mysql.tar.xz >/dev/null
xzcat /var/www/bak/db/2017-05-20-1200_mysql.tar.xz >/dev/null

如果cat出現抱怨，磁碟上的檔案已損壞，並且作業系統偵測到損壞。檢查內核日誌以獲取更多資訊；通常此時需要更換磁碟。如果只是xz抱怨，那麼作業系統沒有偵測到任何損壞，但檔案仍然無效（損壞或截斷）。無論哪種方式，您都將無法恢復該檔案。您需要從離線備份中還原它。

答案2

我沒有看到任何關於如何創建損壞的 tar 檔案的內容？

您說它是來自網站的備份，但您顯示的問題都是在恢復/解壓縮時出現的，因此（來源）是您需要進行故障排除的地方。

如果將備份移至另一台電腦/位置後無法解壓縮文件，則它們必須是建立錯誤或在傳輸過程中損壞。

要定位錯誤的來源：

  • 在網路伺服器上手動建立備份（不含pv和不帶-i）
  • 手動測試網頁伺服器上的備份（不含pv和不帶-i）

如果到目前為止沒有發現問題：

  • 從網頁伺服器複製備份
  • 在目標機器上測試複製的備份（不含pv和不帶-i）

如果到目前為止沒有發現問題，則備份腳本不會像手動建立存檔時那樣建立存檔（並且可能應該修改為手動執行的操作）。

另外，請確保使用所有相關命令的絕對路徑。如果系統中有壞的$PATH和/或$LD_LIBRARY_PATH變數以及入侵者，則您可能正在使用特洛伊木馬二進位文件，這可能會導致意外的副作用。

當然也可能tar涉及不相容的版本，除非兩個系統都是 debian。你可以嘗試強制POSIX- 兩側模式。

答案3

您使用的標誌-i的長形式是--ignore-zeros。這就是為什麼 tar 不會抱怨檔案損壞的原因。因此，如果您想調試 tar 文件，只需刪除該-i選項，您就會得到損壞文件的清單。

還有另外 2 種方法可以在 UNIX 上找到損壞的檔案（一般來說）。我引用另一個問題中給出的答案。

rsync 可用於複製目錄，且如果任何錯誤導致 rsync 終止，則能夠從終止點重新啟動複製。

使用 rsync 的--dry-run選項，您可以查看將複製的內容，而無需實際複製任何內容。--stats和選項--progress也很有用。 and --human-readableor-h更容易閱讀。

例如

rsync --dry-run -avh --stats --progress /path/to/src/ /path/to/destination/

我不確定 Mac OS X 上是否預設安裝了 rsync，但我在 Mac 上使用過它，所以我知道它肯定可用。

要快速檢查子目錄中的檔案是否可以讀取，您可以使用grep -r XXX /path/to/directory/ > /dev/null.搜尋正規表示式並不重要，因為輸出無論如何都會被丟棄。

STDOUT 被重新導向到 /dev/null，因此您只會看到錯誤。

我在這裡選擇 grep 的唯一原因是它的-R遞歸選項。這裡還有許多其他指令可以用來取代 grep，如果與 find 一起使用，甚至更多。

作為參考：尋找損壞的文件

答案4

@MattBianco 回答的推理路線是我將有條不紊地遵循的解決這個特殊問題。

歸零塊表示 EOF，但這取決於區塊因子（預設值是編譯常數，通常為 20）。焦油的--compare|--diff似乎是用--ignore-zeros( -i) 隱式執行的。

鑑於 的額外複雜性pv，我懷疑tar -i正在引起問題xz，查看焦油人對阻塞因子的影響我建議先刪除-i

然後，如果這沒有幫助，請替換為：

--read-full-records --blocking-factor=300

如果你只是在谷歌搜尋後閱讀這篇文章“tar：N 處的一個單獨的零塊”，並且不進行任何管道操作，然後嘗試--ignore-zeros。

相關內容