SFV/CRC32校驗和是否足夠快，可以檢查通用備份文件？

我有3太字節，超過300,000個各種規模的參考文件（每個20,30,40,200 megas），我通常會定期備份它們（不是壓縮文件）。幾個月前，我可能由於數據降級而丟失了一些文件（因爲我沒有通知就「備份」了損壞的文件）。SFV/CRC32校驗和是否足夠快，可以檢查通用備份文件？

我不在乎安全性，所以不需要MD5，SHA等。我只是想確保我複製的文件是好的（相同的位和字節），並驗證備份在完成之後是否完整幾個月後再次備份。

因此，由於這些文件不是很重要的，沒有必要的安全（無敏感信息），我的需求是基本的。我的疑問：「SFV CRC/32」的格式/方法是否符合我的需求？有比這更好，更快的東西嗎？我正在使用程序ExactFile。

是否有任何校驗和比SFV/CRC32更快但是沒有缺陷？我嘗試使用MD5，但速度很慢，由於我不需要數據安全性，所以我更喜歡SFV/CRC32。儘管如此，這還是很痛苦的，因爲有超過30萬個文件需要幾個小時才能完成所有這些文件的校驗和，即使使用CPU Xeon 8核心HT和快速硬盤也是如此。

但從數據完整性的角度來看，存在加盟一個.ZIP或.RAR的所有文件，而不是在文件夾和文件，讓他們「寬鬆」一些優勢？

有些提示？

謝謝！

來源

2015-12-24 Maldon

如果您可以在「幾個月前，我丟失了一些文件」（其中「少數」將被替換爲「每隔幾個」以便獲得一個速率）中量化「少」和「一些」，那麼你可以計算出誤報的概率。不過，從這些話來說，我會說，是的，32位CRC應該適用於您的應用程序。至於速度方面，如果你有一個最新的英特爾處理器，你可能有一個CRC-32C指令，它可以使計算速度提高大約15倍。（某些代碼見this answer）。通過在多個內核上運行它可以更快地完成。如果做得對，你應該受到I/O的限制，而不是計算。

在這種情況下將它們捆綁在一個zip或rar中沒有任何優勢。事實上，如果一個文件損壞會導致你失去一切，情況可能更糟。

來源

2015-12-25 07:39:45

馬克阿德勒，謝謝你的澄清。自1997年以來我在這裏有文件，我一直在從HDD複製到硬盤。所以總是希望使用校驗和來確認一切正常。直到今天，我從未有過很大的損失（只有少量損壞的文件），但我每天都更加偏執地備份。我很快學到的一件事就是永遠不要壓縮文件。關於「誤報」，這意味着即使校驗和正確，某些文件可能會被破壞？再次感謝您的澄清。 – Maldon

是的，如果文件中只有正確的錯誤纔會將CRC恢復爲原始值，則會出現誤報。如果一個文件被破壞，在這種情況下偶然發生的概率非常小，約爲2 ^（ - 32）。由於您的案例中損壞的文件數量似乎非常小，因此該概率應該可以接受。 –

如果你沒有得到吞吐量每核心第二至少250 MB，那麼你很可能I/O或內存速度的約束。假設一個不合理的合理優化實現，CRC32和MD5的原始散列速度甚至比幾十年前的硬件更高。

看一看的Crypto++ benchmark，其中包括了大量的其他的哈希算法爲好。

的Castagnoli酒店CRC32可以比標準的CRC32或MD5快，因爲新的CPU有它特殊的指令;使用該指令和代碼支持（用於並行散列三個流，將部分結果與一些線性代數拼接在一起，等等），則可以將散列加速至大約1個週期/ dword。由於特殊的AES指令，基於AES的散列在近期的CPU上也很快閃現。

但是，在最後的散列函數等待讀取數據的速度並不重要;特別是在多核機器上，你幾乎總是在這樣的應用程序中進行I/O綁定，除非你受到小緩存的破壞以及深度緩存層次結構的延遲。

我會用MD5堅持這是不超過CRC32慢，普遍可用的，即使在最古老的機器，在幾乎每一個編程系統/語言有史以來發明。不要認爲它是一種'加密安全散列'（現在不是，現在不是），而是某種類型的CRC128與CRC32一樣快，但需要一些2^64的散列才能成爲可能，而不像CRC32那樣只有幾萬個。

如果你想推出一些自定義代碼，然後結直腸癌確實有一些優點：文件的CRC可以通過兩個CRC帶着幾分線性代數結合子塊來計算。使用像MD5這樣的一般哈希是不可能的（但是您可以總是並行處理多個文件）。

有很多現成的程序用於計算文件和目錄的MD5哈希快速。我推薦md5sum + cousins的'深'版本：md5deep and hashdeep，你可以找到on SourceForge和on GitHub。

來源

2016-01-01 16:29:10 DarthGizka

達斯Gizka，謝謝你的提示。現在我使用你指出的md5deep 64。這很好。我曾經使用ExactFile，它在2010年停止更新，仍然是32位（沒有64位版本）。我在兩者之間做了一個快速的比較。 ExactFile創建MD5摘要的速度更快。但爲了比較摘要，md5deep64要快得多。

正如你所說，我的問題是硬盤。對於備份和存儲，我使用3個Seagate，每個2TB（7200rpm 64兆緩存）。使用SSD時，程序會更快，但使用TB的文件非常難以使用SSD。

前幾天，我做的過程中檔案的一部分：1萬億（約17個文件）。 ExactFile花費了大約六個小時來創建摘要SFV/CRC32。我使用了一臺配備i7 4770k（嵌入了CRC32指令，8個內核--4個實際和4個虛擬MB MB Gygabyte Z87X-UD4H，16個RAM）的新機器。

在整個文件的計算，則CPU核心是幾乎無法使用（3％至4％，最多20％）。硬盤使用率達到100％，然而，只有他的速度功率的一小部分達到了（sata 3），大部分時間是70 MB/s，有時會降到30 MB/s，具體取決於計算的文件數量和反病毒在後臺（後來我禁用了，就像我經常在複製大量文件時那樣）。

現在我正在測試使用二進制文件進行比較的複製程序。無論如何，我將繼續使用md5摘要。感謝您的信息和任何提示，歡迎光臨。

來源

2016-01-05 02:36:09 Maldon

SFV/CRC32校驗和是否足夠快，可以檢查通用備份文件？

回答

相關問題