碎片導致過多的 vhdx 備份大小
伺服器託管一個名為 MultiCash-Datanbank 的服務。對於每個使用者，它保留兩個記憶體文件（SPASD32.SRC 和 SPASD32Z.SRC），它們的大小以每天約 1MB 的速度增長。每天還會添加一堆小數據文件。三個月來我一直在觀察我們的網路備份，並註意到保存這些數據的分區的 vhdx 映像的大小一直在增長，每天增長 300-900MB。在一個 1TB 的分區上，7GB 的數據最終膨脹成一個 30GB 的 vhdx 文件，我不得不採取行動。
在產生執行 DiskView 的想法之前，我發現的臨時解決方案的時間順序：
- 重新創建分區（來回移動文件合併它們）
- 縮小分區（執行可用空間合併步驟）
- 將分區大小限制為 10GB（將映像大小限制為 10GB）
- 執行手動碎片整理（預設計劃的碎片整理在 2012r2 上不執行任何操作！）
所以。由於某種未知的原因，這些文件的集群以一種非常不尋常的方式排列在磁碟上：
每個 4k 集群與其他集群之間有大約 256 個集群 (1MB) 的可用空間。此外，這些文件大部分時間都是交錯的。這種模式一直持續到覆蓋所有可用空間為止。然後，隨著文件的進一步增長，多個集群的組變得更加頻繁。
不知道這種碎片是由服務本身的寫入模式還是某些 ntfs 優化機制引起的。Fsutil 報告文件未標記為稀疏。Contig 報告說，在這個包含 7GB 數據的 10GB 分區上，大約有 3000 個這樣的片段（= 跨越 3GB 的空間）。如果磁碟映像程序在數據存在時分配一個 1MB 塊，這將是有意義的。我讀過 vhdx 格式包含性能優化，所以這可能是其中之一。那麼不幸的是，它會導致這種最壞的情況。
我也對我完全錯誤的可能性持開放態度，我的觀察與實際原因無關。一個警告信號是膨脹的備份不會壓縮到與優化備份相同的大小 - 對於 100% 的大小膨脹，壓縮數據會增加 25%。
所以最後，我對情況有部分了解，以及一些醜陋的解決方法。我想問：是什麼導致了這種碎片化，以及如何讓它停止？Windows Server Backup 的 vhdx 格式是否真的使用 1MB 塊，如果是，可以更改嗎？
最終，最直接的解決方案是添加自定義碎片整理任務，命令行參數指定“傳統”碎片整理。這將數千個片段合併為連續文件，這反過來又讓 vhdx 圖像避免了由於其 2MB 塊大小而必須包含片段之間的所有空白空間。最終導致問題的伺服器軟體被停用並由軟體提供商託管的門戶網站取代。因此，問題的根源就消失了。碎片整理任務對於保持小型伺服器優化仍然很方便，所以我把它留在那裡。
我從來沒有發現數據庫文件像那樣碎片化的原因。我從軟體供應商那裡得到的回饋說他們沒有收到任何其他類似的報告。它沒有解決導致這種碎片模式的行為的問題，而是專注於備份方法，建議不同的備份格式（因此不同的備份軟體），或更改 WSB 在創建 vhdx 容器時選擇的 BlockSize（但沒有有這樣的選擇）。所以沒有任何幫助或資訊。我對發生的事情有一些猜測，從嘗試手動實現稀疏文件到嘗試對齊數據以讓驅動器磁頭更好地尋找。這兩個聽起來都很奇怪，但有這麼大的公司軟體自 1990 年以來就一直在開發中
至於為什麼內置的 Windows ‘Defrag’ 任務實際上並沒有對驅動器進行碎片整理……嗯，它曾經，但對於 Server 2012 和更新版本，Microsoft 決定預設執行傳統的碎片整理不再實用，因為不斷增長的伺服器儲存容量。據推測，伺服器操作員會知道是否有任何分區需要傳統的碎片整理，並會定義一個自定義任務來處理它。我不知道這種變化。內置任務的命令行從未包含實際的 /D 參數並沒有幫助 - 它在沒有指定任務時依賴於預設行為。新的 Windows 版本包括附加參數，這些參數覆蓋了預設行為。如果一個人只是在尋找被刪除的參數，這種事情就更難發現了。