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 可能造成的影響包括：
  • 格線存取狀態變更為「管理員模式」時，備份或複寫失敗
    • 用戶端備份工作可能會失敗，並顯示與以下類似的訊息：  」avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
  • 備份排程器會自動停用 (直到有人確認並清除為止)
 
達到下列閾值時，Avamar Administration UI 會產生事件警告或錯誤：
  • 80% - 容量警告
  • 95% - 已達健全狀況檢查限制 (在某些情況下，這可能會停用備份排程器，至少直到手動確認為止)
  • 100% - 已達伺服器唯讀限制 (格線會進入管理員模式)

Cause

簡要說明如下：Avamar Server 與 GSAN 容量會對備份資料進行「重複資料刪除」，也就是當出現某些相似的位元組或資料區塊時，系統只需儲存該資料區塊一次。任何資料都可以與在 Avamar 格線上相同或不同用戶端的其他備份資料，進行「重複資料刪除」。由於這些資料區塊很小，系統能夠找出大量的重複資料，並避免重複備份來大幅節省容量。
用戶端備份資料的容量生命週期：
  1. 由於採用了重複資料刪除，Avamar 僅需儲存並保留每次用戶端備份工作之間的小幅變更與差異。執行新的備份工作 (或傳入的複寫) 時，系統可能會新增資料，並提高 Avamar 容量或使用率值。 
  2. 經過一段時間後，備份會根據設定的保留時間和期限而到期，並且不再存在於 Avamar 格線上以供還原。 
  3. 執行 Avamar 的維護工作「垃圾收集」(GC) 時，系統會找出所有唯一資料部分或資料區塊，因這些已到期備份而不再需要。GC 會確認沒有其他目前的備份共用相同的資料 (由於重複資料刪除)，接著移除或釋放這些不再需要的資料區塊，以降低 Avamar Server 的容量或使用率。
 

當每日新增的傳入資料量大致等於每日清理的資料量時，這種狀態稱為「穩定狀態」。這是所有已安裝 Avamar 格線的目標。

在建立並設定完新的 Avamar 格線之前，通常會進行一般安裝前容量估算，以判定儲存備份資料所需的容量。這些估算係依據客戶的保留需求，以及需要備份的資料量而定。估算內容也包括這些資料平均可進行多少重複資料刪除。

然而，在某些情況下，容量可能無法達到穩定狀態。可能的原因如下：
  1. 未持續執行垃圾收集
  2. 垃圾收集效能緩慢或執行時間不足
  3. 在 Avamar 格線安裝之前進行的重複資料刪除估算不夠準確
  4. 實際備份至此 Avamar Server 的資料，包含 Avamar 格線安裝前估算時未納入的其他資料。
  5. 其他原因

Resolution

請確認以下每個故障診斷步驟皆符合該環境的實際情況：

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

步驟 1資料收集：

請確認 Avamar 格線沒有其他與容量不相關的問題。如果有此類問題，則必須在進行容量故障診斷之前先行處理。

這些問題包括硬體錯誤、資料完整性問題 (包含節點離線)、離線等量、檢查點驗證失敗，或維護工作執行失敗。若存在上述任何問題，則必須停止容量故障診斷並處理其他問題。其他問題解決後，才能重新檢視容量狀況。

應執行健全狀況檢查 (Avamar：如何在 Avamar Server 上執行 proactive_check.pl 健全狀況檢查指令檔，至少 status.dpn 該命令可讓您快速概覽並驗證上述多數問題。請參閱 Avamar：如何瞭解 status.dpn 命令產生的輸出

請參閱下列文章，以取得更多資訊：Avamar：如何正確應用「Avamar 故障診斷階層」方法。

如需協助以處理和容量無關的問題，請向 Dell Technologies Avamar 支援團隊建立 SR。

 

步驟 2. 容量資訊收集： 

以下是進行 Avamar 容量問題故障診斷時所需的所有必要資訊：Avamar：如何收集用於容量問題故障診斷的資訊

至少 status.dpn 可透過該命令，或 Avamar Administration 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 Administration UI 中查看。

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

如果 GSAN 容量偏高，且其他相關容量亦偏高，則可依任意順序進行故障診斷 (作業系統容量除外，這必須一律優先處理)。

注意：容量、 GSAN 中繼資料容量以及 DD 容量可能同時偏高。在此情況下，這些容量問題可依任意順序處理，不同於一律必須優先處理的作業系統容量問題。
 
 
 

步驟 5. 等量平衡和作業系統磁碟平衡：

Avamar 中的「等量」是用於儲存備份資料的容器檔案，存在於資料節點上 (單一節點的 Avamar 格線除外)。

原則上，等量應在格線中的不同磁碟與節點之間保持「平衡」，亦即平均分佈；然而，在某些情況下，等量可能會出現不平衡的情形。

依 Avamar 的設計，當涉及 Avamar 容量時，最大的節點或磁碟分割區即為限制因素。

此設計係為避免任何磁碟或節點建立超出其可處理 (或允許) 數量的等量，因此維持等量的平衡對容量而言相當重要。

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

注意：雖然理想狀態是達到完全的等量平衡，實務上也經常可見，但在某些情況下可能會出現「不完全」平衡但相當接近平衡的狀態。Avamar 工程團隊已確認，等量平衡之間允許存在 4% 的差異與容忍範圍，且仍屬於預期範圍內。
 
 

另一種需要瞭解的平衡類型是作業系統磁碟平衡。此情況僅限於同一節點上的資料分割區，不適用於多個節點上的分割區。 

如果在同一個資料節點上，某一分割區的容量明顯大於或小於同一節點上的另一個分割區，則可能會超出一項稱為「freespaceunbalance」的限制。雖然此問題通常屬於作業系統層級，而非 GSAN 容量本身，但仍可能被回報為 GSAN 容量問題。

 

步驟 6. 檢查垃圾收集是否已完成： 

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

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 已達到其最大允許執行時間，但在未發生任何錯誤的情況下安靜且正常地結束。本步驟中的資訊有助於確認是否發生此情況。
 
 

a. 執行下列命令，以檢查 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 為非零值，請計算 maxtime的 2/3，並將其與已經過時間做比較。
(以上述範例而言，14400 的 2/3 為 9600，而所有已經過時間的輸出皆遠低於此數值。)

  • 如果 elapsed-time 小於 maxtime的 2/3，則很可能是因為已無資料可收集，因此提前完成 GC。

  • 如果通過的次數偏高 (14 次或以上)，則很可能表示 GC 正在移除足夠數量的資料。
    注意：請理解，如果沒有資料到期且無資料需要清理，則通過的數值預期會偏低，因此也應一併瞭解整體情況與環境。請勿假設通過次數較少即代表存在問題。
 

各種因素都可能導致 GC 執行緩慢，或未能完整掃描所有資料。這些因素包括過去未能連續執行足夠長的時間或天數、設定不正確、發生錯誤等狀況。

如果對 maxtime或通過次數有任何疑慮，請向 Dell Technologies Avamar 支援團隊建立 SR，以進一步進行調查。

 

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

若已確認 GC 的執行時間夠長，則可能是垃圾收集控制之外的原因，導致資料未被收集。以下列出一般應檢查的已知原因：

a. 確認備份至少設定為有最終期限或會定期到期。如果備份不會經常到期，GC 就不會有太多可處理的資料。

b. 使用下列文章找出「變更率最高」的用戶端：Avamar：如何使用 capacity.sh 指令檔管理容量。(請一併檢視「% OF TOTAL」與「CHGRATE」。)

c. 依照下列文章檢查略過的雜湊：Avamar：Avamar 垃圾收集報告中可能出現無法清理的「略過的雜湊」。如果此情況偶爾發生但次數不多，屬於正常現象並可略過。

d. 存在一個旗標或選項，會強制 Avamar Server 保留每個用戶端最後一次與最近一次的備份。此設定是出於安全性考量，避免用戶端的所有備份都意外到期。然而，這在資料清理與垃圾收集時可能會導致其他問題。Dell Technologies Avamar 支援團隊可協助確認此設定是否已啟用。

e. 如果近期已將備份從 GSAN 切換至 DD 後端，或發生非預期的 GSAN 備份，但 GSAN 容量未下降，請向 Dell Technologies Avamar 支援團隊建立 SR，以進一步進行調查。

 

步驟 9.Avamar 格線的規模不足以因應目前或預期將新增的資料量：

在檢視所有可能導致容量偏高的解決方案與原因，且確認並非設定問題或誤新增資料所致後：

這表示可能需要刪除資料或評估其他選項，例如將部分用戶端遷移至其他 Avamar 格線和新增資料節點等。

 

步驟 10.確認所有容量事件，並視需要恢復備份排程器：

a. 在容量問題處理完畢後，請於 Avamar Admin UI 中確認所有與容量相關的事件。

b. 恢復備份排程器：

dpnctl start sched
 

如欲瞭解 Avamar 容量的其他問題、訓練、故障診斷等，請參閱：Avamar：容量故障診斷、問題與常見疑問 - 所有容量 (解決方案路徑)

Additional Information

不建議執行手動或「積極」垃圾收集。
(此處係指在排程的自動時間之外執行垃圾收集。)
  • 這個動作本身可能會「掩蓋」並隱藏真正的問題，只會讓問題在數天或數週後再次出現，導致此次手動工作成為徒勞。
  • 此外，在排程之外執行手動垃圾收集，會造成無法以正常效率運作。
 
上述解決步驟完全未提及亦未建議變更與「容量」相關的最大磁碟與 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.