Avamar GSANまたはユーザー容量に関する解決パス

オペレーティング システム(OS)容量の初期概念と理解については、次の記事を参照してください。「Avamar：容量に関する一般的なトレーニング - 解決パス」

多くの場合、 GSAN 容量は、クライアント バックアップのための容量と使用状況として考えるのが最もわかりやすいです。

• 重複排除の基本的な理解
• チェックポイント、チェックポイント検証(hfscheck)、ガベージ コレクションの基本的理解と、それぞれの重要性
• The difference between GSAN （またはユーザー）容量とOS容量の違い
• 変更率
• 定常状態

• グリッドのアクセス状態が「admin mode」に変更された場合のバックアップやレプリケーションの失敗

  • クライアント バックアップ ジョブが次のようなメッセージで失敗する場合があります：  」avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
• バックアップ スケジューラーの自動無効化（誰かが確認してクリアするまで有効化されない）

• 80% - 容量警告
• 95% - 正常性チェックの上限に到達（場合によってはバックアップ スケジューラーが無効になることがあります。手動で確認されるまで有効化されません）
• 100% - サーバー読み取り専用の上限に到達（グリッドは管理者モードになります）

1. Avamarでは、重複排除により、各クライアント バックアップジョブ間の小さな変更点と相違点のみを保存するだけで済みます。新しいバックアップ（または受信レプリケーション）を実行すると、新しいデータが追加され、Avamarの容量や使用率が増加する可能性があります。 
2. 一定の時間が経過すると、バックアップは設定された保持期間および有効期限に基づいて期限切れとなり、Avamarグリッド上で復元可能な状態ではなくなります。 
3. ガベージ コレクション(GC)と呼ばれるAvamarのメンテナンス ジョブが実行されると、これらの期限切れバックアップにより不要となった、固有のデータ チャンクがすべて検出されます。GCは、他の現行バックアップが同じデータを共有していないことを確認した上で（重複排除のため）、不要となったデータ チャンクを削除または解放し、Avamar Serverの容量や使用率を削減します。

日々追加される受信データ量と、日々クリーンアップされるデータ量がほぼ同じ状態を「定常状態」と呼びます。これは、導入されるすべてのAvamarグリッドが理想とする状態です。

新しいAvamarグリッドを設定および構成する前に、一般的な設置前のサイズ計算が行われ、バックアップ データの保存に必要な容量を算出します。これらの計算は、お客様のデータ保持要件およびバックアップ対象データ量に基づいています。さらに、この計算では、平均的にどれくらいのデータが重複排除されるかも推定されます。

1. ガベージ コレクションが定期的に実行されていない
2. ガベージ コレクションのパフォーマンスが遅い、または十分な時間実行されていない
3. Avamarグリッド設置前の重複排除の見積りが正確ではなかった
4. Avamarグリッド設置前に想定されていなかったデータがこのAvamar Serverにバックアップされている
5. その他の理由

以下の各トラブルシューティング手順が環境に当てはまるかどうか確認してください。

ステップ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 容量を確認できます。

手順3.OS容量がいっぱいかどうかを確認する：

以下のコマンドは、各ディスク パーティションのOS容量の現在の値を表示するのに役立ちます。いずれかの値が85%に達しているか、それを超えている場合は（2番目のサンプル出力のように）、OS容量が高いと判断されます。

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"

OS容量が85%未満の場合にのみ、 GSAN 容量のトラブルシューティングを続行してください。 

手順4.容量以外の問題（容量の問題と誤解されることがあるもの）：

クライアントのバックアップが失敗する原因は、必ずしも「容量」ではなく、「クォータ」にある場合があります。こうしたケースは、容量問題と誤解されることがあります。

この状況は、 status.dpn コマンドやその他の収集された出力を確認することで、実際には容量が低いことを確認することで判別できます。

また、クライアント バックアップが失敗したり実行されなかった原因が、 Non-GSAN 容量以外の理由である場合もあります。収集された情報でこのことを確認できます。または、Avamar Administration UIでも確認可能です。

• Avamar：メタデータ容量解決パス（英語）」
• 「Data Domain：Avamar統合の解決パスからの高容量」

ここで、 GSAN 容量が高く、その他の容量も高い場合、トラブルシューティングは任意の順序で実行できます（ただし、OS容量は常に最初に確認する必要があります）。

手順5.ストライプのバランスとOSディスクのバランス：

Avamar上の「ストライプ」は、データノード上でバックアップ データが格納されているコンテナー ファイルです（シングルノードAvamarグリッドを除く）。

ストライプは、グリッド内のさまざまなディスクやノードに均等に分散されている（バランスが取れている）ことが期待されますが、場合によっては不均等になることがあります。

Avamarの設計上、容量に関しては最大のノードまたはディスク パーティションが制限要因となります。

これは意図的な設計で、どのディスクやノードも処理できる（または許可されている）よりも多くのストライプを作成しないように制限されています。そのため、ストライプのバランスを保つことは容量管理において重要です。

たとえば、Avamarグリッド拡張のためにデータ ノードを追加する場合は、ストライプのバランス調整を行い、新しいノードに均等にストライプを分散させることで、全体のAvamar容量割合を減らす必要があります。

理解しておく必要があるもう1つのタイプのバランスは、OSディスク バランスです。これは、同一ノード上のデータ パーティション間に限定されるものであり、複数ノード間のパーティションには適用されません。 

同一のデータ ノード上で、あるパーティションのサイズが同じノードの別のパーティションよりもはるかに大きい、または小さい場合は、次のように呼ばれる制限を超える場合があります「freespaceunbalance」。これは通常、 GSAN 容量ではなくOS容量の問題ですが、 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は十分な時間実行されているか？

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 に保存されているデータの1つの層を表しています）。

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であり、すべての経過時間の出力はこの値を十分に下回っています。）

さまざまな要因により、GCの実行が遅くなったり、すべてのデータをスキャンできなかったりする場合があります。これには、過去に十分な時間（あるいは日数）GCが実行されていなかったこと、設定の不備、エラーの発生などが含まれます。

「 maxtime」やパス数について懸念がある場合は、詳細を調査するためにDell Technologies Avamarサポート チーム宛てにサービス リクエストを作成してください。

手順8.GCが期待される量のデータを削除していない可能性がある場合：

GCが十分な時間稼働していることを確認した場合でも、ガベージ コレクション制御範囲外の理由でデータが収集されないことがあります。一般的に確認すべき理由は以下の通りです。

a.バックアップが最終的に期限切れになるよう、または定期的に期限切れになるように設定されているか確認してください。期限切れのバックアップが少ない場合、GCの処理対象は少なくなります。

b.次の記事を参照して、「上位変更率」クライアントを確認します：「Avamar：capacity.shスクリプトを使用して容量を管理する方法」（% OF TOTALおよびCHGRATEの両方を確認）。

c.次の記事を参照して、スキップされたハッシュを確認します：「Avamar v7以降：データの使用中に「ハッシュ参照ビット マップ」が原因でクリーンアップできない「スキップハッシュ」を報告するガベージ コレクション」これらがまれに発生している場合は通常の動作とみなし、スキップできます。

d. Avamar Serverには、各クライアントからの最新のバックアップを強制的に保持するフラグまたはオプションがあります。これは、クライアントが誤 ってすべてのバックアップを失効させるのを防ぐための安全策です。ただし、これが原因で、データのクリーンアップやガベージ コレクションに他の問題が発生する可能性があります。デル・テクノロジーズのAvamarサポート チームは、この機能が有効になっているかどうかを確認することができます。

e. バックアップが最近 GSAN からDDバックエンドへ切り替えられた場合、または誤って GSAN バックアップが作成された場合に、 GSAN 容量が減少しないことがあります。この場合は、詳細を調査するためにDell Technologies Avamarサポート チーム宛てにサービス リクエストを作成してください。

手順9.現在のまたは今後追加されるデータ量に対してAvamarグリッドの容量が不足している場合：

他のすべての解決策や高容量の原因が確認され、それが設定ミスや誤って生成されたデータの問題ではない場合：

データの削除が必要になる可能性があります。あるいは、特定のクライアントを他のAvamarグリッドに移行する、新しいデータ ノードを追加するなどのオプションを検討する必要があります。

手順10.容量イベントを確認し、必要に応じてバックアップ スケジューラーを再開する：

a.容量の問題が解消されたら、Avamar管理UIで容量関連のすべてのイベントを確認します。

b.バックアップ スケジューラーを再開します。

dpnctl start sched

その他のAvamar容量に関する質問、トレーニング、トラブルシューティングなどについては、次の記事を参照してください。「Avamar：容量のトラブルシューティング、問題、質問 - すべての容量（解決パス）」

• この操作自体が、実際の問題を「隠す」ことになり、数日または数週間後に再び問題が表面化する可能性があり、手動での作業が無駄になることがあります。
• さらに、手動GCはスケジュール外で実行されるため、効率的に動作しない場合があります。
  • 場合によっては、他の問題を悪化させることもあります。詳細については、次を参照してください。Avamar：手動ガベージ コレクションの使用について」

• このような変更や操作は、通常は実行されず、デフォルトで検討すべきではありません。AvamarのL2エンジニアまたは対象分野のエキスパート(SME)に、変更を承認してもらう必要があります。
• 残念ながら、このような操作は、多くの場合、Avamarグリッドに恒久的な損傷を与える可能性があり、ストレージ ノードの追加や再導入によってのみ解決可能となることがあります。

上記のいずれの操作も実行しないのは、サポート チームが容量問題を最も有益な方法で解決することを望んでいるためです。