Avamar GSAN 或使用者容量解決方案路徑

Summary: 此解決方案路徑文章用於處理和故障診斷 Avamar 上的 GSAN 容量 （亦即使用者容量） 問題。

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Symptoms

如需作業系統 （OS） 容量的初始概念和瞭解，請參閱 Avamar：容量一般訓練 - 解決方案路徑

這通常是最容易考慮的 GSAN 作為用戶端備份空間和利用率的容量。

如本培訓文章所述，若要繼續閱讀本文的其餘部分，應要求對以下主題有合理的理解：
  • 對重複資料刪除的基本瞭解
  • 基本瞭解檢查點、檢查點驗證 （hfscheck），和垃圾回收，以及每個的重要性。
  • 兩者的區別 GSAN （或使用者）容量和作業系統容量
  • 變更率
  • 穩定狀態
 
高的影響 GSAN 容量包括：
  • 當格線存取狀態變更為「admin mode」時，備份或複寫會失敗
    • 用戶端備份工作可能會失敗，並顯示類似以下的訊息：  」avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
  • 自動停用備份排程器（直到有人確認並清除）
 
超過下列閾值時，Avamar 管理 UI 中會產生事件警告或錯誤：
  • 80% - 容量警告
  • 95% - 已達到執行狀況檢查限制 （這有時會停用備份排程器，至少在手動確認之前是如此）
  • 100% - 已達到伺服器唯讀限制 （格線進入管理模式）

Cause

在快速摘要中：Avamar Server 和 GSAN 容量會「重複資料刪除」備份資料，也就是說，當特定位元組或資料區塊相似時，只需要儲存該區塊一次。任何資料都可以根據備份在 Avamar 格線上的相同或不同用戶端的任何其他資料，進行「重複資料刪除」。由於這些數據塊很小，因此可以找到許多重複項並節省大量容量，而不必重複備份。
用戶端備份資料的容量生命週期：
  1. 由於重複資料刪除的緣故，Avamar 只需要儲存和儲存每個用戶端備份工作之間的細微變更和差異。執行新的備份 （或傳入複寫） 時，可能會新增資料並增加 Avamar 容量或使用率值。 
  2. 一段時間後，備份將會根據其設定的保留和到期而到期，且在 Avamar 格線上找不到可還原的備份。 
  3. 當名為垃圾收集 （GC） 的 Avamar 維護工作執行時，它會找到由於這些過期的備份而不再需要的所有唯一資料部分或區塊。GC 會確認目前沒有其他備份共用相同的資料 （因為重複資料刪除）， 然後移除或釋放不再需要的資料區塊，以降低 Avamar Server 容量或使用率。
 

當添加的每日傳入數據量與要清理的每日數據量大致相同時，這稱為“穩定狀態”。這是每個已安裝 Avamar 格線的目標。

在設定和設定新的 Avamar 格線之前，會進行一般預先安裝大小運算，以判斷儲存備份資料所需的容量。這些計算基於客戶的保留要求和要備份的數據量。它還估計平均可以刪除重複數據的數據量，依此類推。

但是，有時容量無法達到穩定狀態。這可能是由以下原因造成的：
  1. 垃圾收集未持續執行
  2. 垃圾收集效能緩慢或執行時間不夠長
  3. 安裝 Avamar 電網之前的重複資料刪除預估不夠準確
  4. 非在安裝 Avamar 電網之前所計算的資料，將會備份到此 Avamar 伺服器。
  5. 其他原因

Resolution

驗證以下每個故障診斷步驟是否適用於環境：

注意：這些步驟為最適當的順序，以隔離問題並找出適當的解決方法。
請勿跳過任何步驟。
 
 

步驟 1資料收集：

請確定 Avamar 格線沒有其他非容量問題。如果有，在故障診斷容量之前，可能需要先注意。

這包括硬體錯誤、資料完整性問題 （包括離線節點）、離線等量、檢查點驗證失敗或維護工作失敗。如果這些是其中任何一個問題，則必須停止對容量進行故障排除，並解決其他問題。一旦其他問題得到解決，就可以重新訪問容量。

應執行狀況檢查 （Avamar：如何在 Avamar Server 上執行 proactive_check.pl 執行狀況檢查指令檔，但至少 status.dpn 命令可以快速概述和驗證大多數相同的問題。請參閱 Avamar：如何瞭解 status.dpn 命令產生的輸出

如需其他資訊，請參閱下列文章：Avamar：如何正確套用「Avamar 故障診斷階層」方法。

如果需要協助來解決任何非容量問題，請向 Dell Technologies Avamar 支援小組建立服務要求 。

 

第 2 步 。 容量資訊收集： 

請參閱以下資料，以取得故障診斷 Avamar 容量問題所需的所有必要資訊：Avamar：如何收集資訊以故障診斷容量問題

至少， status.dpn 命令或 Avamar 管理 UI 中的值顯示 GSAN 量。

注意：顯示的容量如下 status.dpn 命令和UI因預期設計而異。
 
 

第 3 步。檢查作業系統容量是否已滿：

下列命令可協助顯示每個磁碟分割的作業系統容量目前值。如果任何值達到或超過 85%，如第二個範例輸出所示，則將其視為高作業系統容量：

avmaint nodelist | egrep 'nodetag|fs-percent-full'
 

範例輸出：

nodetag="0.2"
        fs-percent-full="56.6"
        fs-percent-full="54.7"
        fs-percent-full="54.4"
        fs-percent-full="54.6"
        fs-percent-full="54.7"
        fs-percent-full="54.7"
      nodetag="0.1"
        fs-percent-full="56.2"
        fs-percent-full="54.6"
        fs-percent-full="54.6"
        fs-percent-full="54.8"
        fs-percent-full="54.8"
        fs-percent-full="54.5"
      nodetag="0.0"
        fs-percent-full="56.2"
        fs-percent-full="54.7"
        fs-percent-full="54.8"
        fs-percent-full="54.7"
        fs-percent-full="54.6"
        fs-percent-full="54.6"
  
nodetag="0.2"
        fs-percent-full="94.5"
        fs-percent-full="94.4"
        fs-percent-full="94.2"
        fs-percent-full="94.1"
        fs-percent-full="94.0"
        fs-percent-full="94.0"
      nodetag="0.1"
        fs-percent-full="94.5"
        fs-percent-full="94.3"
        fs-percent-full="94.1"
        fs-percent-full="93.6"
        fs-percent-full="94.0"
        fs-percent-full="93.9"
      nodetag="0.0"
        fs-percent-full="94.4"
        fs-percent-full="94.4"
        fs-percent-full="94.0"
        fs-percent-full="94.1"
        fs-percent-full="92.7"
        fs-percent-full="92.5"
 
警示：雖然高作業系統容量似乎不是最大的問題，但這會導致無法進行故障診斷 GSAN 容量，因為如果容量超過 89%，垃圾收集將無法執行。我們會更詳細地討論這個問題，並在以下位置提供故障診斷步驟：Avamar：作業系統 （OS） 容量 （解決方案路徑）
 

只有在作業系統容量低於 85% 時，才應 GSAN 容量故障診斷仍在繼續。 

 

第 4 步 。 有時可能誤解為容量的非容量問題：

用戶端備份失敗可能不是因為「容量」原因，而是「配額」原因。這些有時可能會被誤解為容量。

這種情況可以通過 status.dpn 命令或其他一些收集到的輸出顯示容量較低。

此外，用戶端備份也可能由於其他原因而失敗或未執行 Non-GSAN 容量原因。收集的資訊應可確認這一點，或也可以在 Avamar 管理 UI 中看到。

如果 GSAN 容量不高，請參閱以下文章：
 

如果 GSAN 容量很高，而且這些其他容量也很高，因此可以任何順序執行故障診斷 （作業系統容量必須始終排在第一位除外）。

注意：有可能 GSAN 容量、中繼資料容量和 DD 容量可能很高。在這些情況下，可以按任何順序處理它們，這與必須始終首先處理的操作系統容量不同。
 
 
 

第 5 步。等量平衡和作業系統磁碟平衡：

Avamar 上的「Stripe」是儲存備份資料在資料節點上的容器檔案 （單節點 Avamar 格線除外）。

預期等量會「平衡」或均勻分佈於網格內的不同磁碟和節點，但有時可能會變得不平衡。

根據 Avamar 的設計，最大的節點或磁碟分割區是 Avamar 容量的限制因素。

這是有意為之，因此磁碟或節點所建立的等量不會超過其可處理 （或允許） 的數量，因此擁有平衡的等量對容量非常重要。

例如，為 Avamar 格線擴充新增額外的資料節點時，必須執行平衡以將等量平均分配至新節點，以降低整體 Avamar 容量百分比。

注意：雖然人們想要完美的等量平衡，而且經常可以看到，但問題可能會出現且「不完全是」，但可以看到接近的平衡。Avamar 工程團隊已確認，等量平衡之間 4% 的差異和容差在預期範圍內。
 
 

需要瞭解的另一種平衡類型是操作系統磁碟平衡。這僅限於同一節點上的數據分區，而不是多個節點上的分區。 

如果在同一數據節點上，一個分區比 SAME 節點的另一個分區大或小得多，則可以超過稱為”freespaceunbalance」。雖然這通常是在作業系統上，而不是 GSAN 容量，可回報為 GSAN 容量問題。

 

第 6 步 。 檢查垃圾收集是否已完成： 

執行下列命令以取得垃圾收集的相關資訊：

dumpmaintlogs --types=gc --days=30 | grep "4201\|2402"
 

理想情況下，輸出會顯示 GC 在過去 30 天內已完成：

2025/10/07-12:00:35.24911 {0.1} <4201> completed garbage collection
2025/10/08-12:00:34.61185 {0.1} <4201> completed garbage collection
2025/10/09-12:00:35.14874 {0.1} <4201> completed garbage collection
2025/10/10-12:00:34.67986 {0.1} <4201> completed garbage collection
2025/10/11-12:00:34.73284 {0.1} <4201> completed garbage collection
2025/10/12-12:00:33.23205 {0.1} <4201> completed garbage collection
2025/10/13-12:00:33.41448 {0.1} <4201> completed garbage collection
2025/10/14-12:00:35.70726 {0.1} <4201> completed garbage collection
2025/10/15-12:00:35.08316 {0.1} <4201> completed garbage collection
2025/10/16-12:00:34.82681 {0.1} <4201> completed garbage collection
2025/10/17-12:00:35.29262 {0.1} <4201> completed garbage collection
2025/10/18-12:00:35.24618 {0.1} <4201> completed garbage collection
2025/10/19-12:00:34.56531 {0.1} <4201> completed garbage collection
2025/10/20-19:06:45.15574 {0.1} <4201> completed garbage collection
2025/10/21-12:00:34.21062 {0.1} <4201> completed garbage collection
2025/10/22-12:00:35.29770 {0.1} <4201> completed garbage collection
2025/10/23-12:00:36.13041 {0.1} <4201> completed garbage collection
2025/10/24-12:00:35.52502 {0.1} <4201> completed garbage collection
2025/10/25-12:00:35.93730 {0.1} <4201> completed garbage collection
2025/10/26-12:00:35.55037 {0.1} <4201> completed garbage collection
2025/10/27-12:00:36.12049 {0.1} <4201> completed garbage collection
2025/10/28-12:00:35.75633 {0.1} <4201> completed garbage collection
2025/10/29-12:00:34.85499 {0.1} <4201> completed garbage collection
2025/10/30-12:00:34.96325 {0.2} <4201> completed garbage collection
2025/10/31-12:00:35.39840 {0.0} <4201> completed garbage collection
2025/11/01-12:00:35.11248 {0.0} <4201> completed garbage collection
2025/11/02-13:00:34.39202 {0.0} <4201> completed garbage collection
2025/11/03-13:00:34.70587 {0.0} <4201> completed garbage collection
2025/11/04-13:00:34.18799 {0.0} <4201> completed garbage collection
2025/11/05-13:00:34.44950 {0.0} <4201> completed garbage collection
 

GC 失敗訊息可能包括但不限於以下內容：

2025/11/04-13:00:01.62234 {0.1} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR
2025/11/01-12:35:06.62868 {0.2} <4202> failed garbage collection with error MSG_ERR_BACKUPSINPROGRESS
2025/10/13-12:20:07.35498 {0.7} <4202> failed garbage collection with error MSG_ERR_TRYAGAINLATER
2025/10/27-12:07:44.35485 {0.0} <4202> failed garbage collection with error MSG_ERR_DISKFULL
2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_MISC
2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_TIMEOUT
2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_GARBAGECOLLECT
 

如果 GC 一直失敗，請先使用下列文章作為參考來解決此問題：Avamar：故障診斷垃圾收集 （GC） 故障 （解決方案路徑）
（若問題已解決，請前往下一個步驟。）

 

第 7 步 。 GC 執行時間是否足夠長？

警告：請勿將此與 GC 結果中的「MSG_ERR_TIMEOUT」混淆。該錯誤完全是另一回事，可在 GC 錯誤解決路徑一文中解決。在這裡，超時意味著在 GC 中達到了其最大運行時間，但安靜乾淨地完成，沒有任何錯誤。此步驟中的資訊有助於確認是否發生這種情況。
 
 

一個。執行下列命令以檢查允許的最長 GC 時間：

dumpmaintlogs --types=gc --days=30 | grep gcflags
 

範例輸出：

2025/10/07-12:00:20.05509 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/08-12:00:20.09141 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/09-12:00:20.42307 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/10-12:00:20.47775 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
...
2025/11/02-13:00:19.76100 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/03-13:00:19.92093 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/04-13:00:19.42781 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/05-13:00:19.74984 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
 

請注意 maxtime 值，在本例中為 14400（秒）。
（值為 0 表示無限制）

b.運行以下命令以確定 GC 的運行時間以及完成的「傳遞」數：
（傳遞與存儲的備份數據的層有關。想想 GSAN 容量像洋蔥層。必須先撕下或取下外層，才能看到內層。每個刀路都是 GSAN 存儲的數據。

dumpmaintlogs --types=gc --days=30 | grep passes | cut -d ' ' -f1,14-20
 

範例輸出：

2025/10/07-12:00:35.24463 passes="24" start-time="1758283220" elapsed-time="250" end-time="1758283235"/>
2025/10/08-12:00:34.60779 passes="3" start-time="1758369620" elapsed-time="70" end-time="1758369627"/>
2025/10/09-12:00:35.14232 megabytes-recovered="1" passes="4" start-time="1758456020" elapsed-time="85" end-time="1758456028"/>
2025/10/10-12:00:34.67590 passes="3" start-time="1758542420" elapsed-time="72" end-time="1758542427"/>
...
2025/11/02-13:00:34.38348 megabytes-recovered="2" passes="18" start-time="1762088419" elapsed-time="89" end-time="1762088427"/>
2025/11/03-13:00:34.69743 passes="18" start-time="1762174819" elapsed-time="9" end-time="1762174828"/>
2025/11/04-13:00:34.17943 megabytes-recovered="8" passes="22" start-time="1762261219" elapsed-time="134" end-time="1762261228"/>
2025/11/05-13:00:34.44187 megabytes-recovered="2" passes="16" start-time="1762347619" elapsed-time="119" end-time="1762347628"/>

 

記下通過次數和 elapsed-time （秒）。

 

c. 假設 maxtime 為非零，計算 2/3 maxtime，並將其與經過的時間進行比較。
（在上面的示例中，14400 的 2/3 是 9600，所有經過的時間輸出都遠低於此數位。

  • 如果 elapsed-time 小於 2/3 maxtime，很可能GC提前完成，因為沒有什麼可以收集的，被趕上了。

  • 如果傳遞次數很高（14 次或更多），則 GC 可能正在刪除足夠數量的數據。
    注意：請注意，如果沒有數據過期並且沒有要清理的內容，則傳遞的價值應該會很低，因此最好也瞭解整個情況和環境。不要認為很少的傳遞意味著存在問題。
 

各種問題可能會導致 GC 執行緩慢，或無法掃描所有內容。這可能包括過去很長一段時間或幾天都沒有足夠的時間運行、不正確的配置、錯誤等。

如果對 maxtime或通過次數，請向 Dell Technologies Avamar 支援小組建立服務要求 以進一步調查。

 

第 8 步。如果懷疑 GC 沒有移除足夠或預期的資料：

如果確認 GC 執行時間足夠長，則可能是因為垃圾收集無法控制之外的原因而無法收集資料。以下是通常應檢查的記錄原因清單：

一個。驗證備份是否配置為至少最終過期或定期過期。如果沒有經常到期的備份，GC 將沒有太多工作要做。

b.使用本文尋找「最高變更率」用戶端：Avamar：如何使用 capacity.sh 指令檔管理容量。（回顧”% OF TOTAL“和”CHGRATE".)

c. 檢查每個 Avamar 是否有略過的雜湊：Avamar 垃圾收集報告無法清理的「略過雜湊」。如果發生但很少見，這是正常現象，可以跳過。

d.d. 有一個旗標或選項會強制 Avamar 伺服器保留每個用戶端的最後一個與最新的備份。這是為了安全起見，這樣用戶端就不會讓每個備份都意外過期。但是，這可能會在涉及數據清理和垃圾收集時導致其他問題。Dell Technologies Avamar 支援小組可以確認是否已啟用此功能。

e.如果最近從 GSAN 到 DD 後端或發生意外 GSAN 備份，但 GSAN 容量未減少，請向 Dell Technologies Avamar 支援小組 建立服務要求 以進一步調查。

 

第 9 步。Avamar 格線大小不足，無法容納目前或預期的新增資料量：

一旦已針對高容量審查所有其他解決方案和可能原因，且這不是組態問題或意外資料問題：

這表示資料可能需要刪除或探索選項，例如將特定用戶端遷移至其他 Avamar 格線、新增資料節點等。

 

第10步。確認任何容量事件，並視需要恢復備份排程器：

一個。解決容量問題後，請在 Avamar Admin UI 中確認所有與容量相關的事件。

b.繼續備份排程器：

dpnctl start sched
 

如需任何其他 Avamar 容量問題、訓練、故障診斷等，請參閱：Avamar：容量故障診斷、問題及問題 - 所有容量 （解決方案路徑）

Additional Information

不建議手動或「主動」垃圾收集。
（這是指在排定的自動時間以外執行 GC。）
  • 此動作本身可能會「遮蔽」並隱藏真正的問題，只會讓它們在幾天或幾週後再次出現，導致這項手動作業浪費時間。
  • 此外，手動 GC 的運行效率可能不如超出計劃。
 
上述解決方案步驟未提及或建議變更 GSAN 容量。
  • 此變更或動作通常不會執行，因此預設情況下不應予以考慮。Avamar L2 工程師或主題專家 （SME） 必須核准此變更。
  • 可惜的是，此類動作通常會以多種方式對 Avamar 格線造成永久性損壞，而這些損害只能透過新增額外的儲存節點或重新部署來解決。
 

請注意，由於支持團隊希望以最有益的方式幫助解決容量問題，因此不會執行上述任何操作。

Affected Products

Avamar

Products

Avamar, Avamar Server
Article Properties
Article Number: 000164132
Article Type: Solution
Last Modified: 07 Nov 2025
Version:  10
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.