Avamar GSANまたはユーザー容量解決パス

オペレーティング システム(OS)容量の初期概念と理解については、「 Avamar: 容量に関する一般的なトレーニング - 解決パス

多くの場合、最も簡単に検討できます GSAN クライアント バックアップの容量と使用率。

• 重複排除に関する基本的な知識
• チェックポイントの基本的な理解、チェックポイントの検証 (hfscheck)、ガベージコレクション、およびそれぞれの重要性について説明します。
• 違いは GSAN (またはユーザー)容量とOS容量
• 変更率
• 定常

• グリッド アクセス状態が「管理モード」に変更された場合にバックアップまたはレプリケーションが失敗する

  • クライアント バックアップ ジョブが次のようなメッセージで失敗することがあります。  」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サーバーの容量または使用率を削減します。

追加される毎日の受信データの量が、クリーニングされる毎日のデータの量とほぼ同じである場合、これを「定常状態」と呼びます。これは、インストールされているすべての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トラブルシューティング階層」アプローチを正しく適用する方法

容量以外の問題に対処するためにサポートが必要な場合は、デル・テクノロジーズのAvamarサポート チームと一緒にサービス リクエストを作成し てください。

ステップ 2。 容量情報の収集: 

Avamar容量の問題のトラブルシューティングに必要なすべての情報については、以下を参照してください。Avamar：容量の問題をトラブルシューティングするための情報を収集する方法(英語)」

少なくとも、 status.dpn コマンドを実行するか、Avamar管理UI内の値に GSAN 能力。

ステップ3。OS容量がいっぱいかどうかを確認します。

次のコマンドは、各ディスク パーティションのOS容量の現在の値を表示するのに役立ちます。2番目の出力例のように、いずれかの値が85%に達したか、85%を超えた場合は、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管理UIでも確認できます。

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

ここで、 GSAN 容量が高く、その他の容量も高い場合、トラブルシューティングは任意の順序で実行できます(OSの容量を常に最初に行う必要がある場合を除く)。

ステップ5.ストライプ バランスとOSディスク バランス:

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

ストライプは、グリッド内のさまざまなディスクとノード間で「バランス」が取れている、つまり均等に分散されていることが期待されていますが、ストライプがアンバランスになる場合があります。

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

これは意図的なものであり、いずれのディスクまたはノードも処理可能(または許容される)以上のストライプを作成しないため、バランスの取れたストライプを持つことは容量にとって重要です。

たとえば、Avamarグリッド拡張のためにデータ ノードを追加する場合は、バランシングを実行してストライプを新しいノードに均等に分散し、全体的なAvamar容量の割合を下げる必要があります。

理解が必要なバランスのもう1つのタイプは、OSディスクのバランスです。これは、同じノード上のデータ パーティションのみに限定され、複数のノード上のパーティションには制限されません。 

同じデータノード上で、1つのパーティションがSAMEノードの別のパーティションよりもはるかに大きいまたは小さい場合、制限を超える可能性があります。freespaceunbalance」。これは通常、OS上にありますが、 GSAN 容量は、次のように報告できます。 GSAN 容量の問題。

ステップ 6. ガベージ コレクションが完了しているかどうかを確認します。 

次のコマンドを実行して、ガベージ コレクションに関する情報を取得します。

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

出力には、過去30日間にGCが完了したことが表示されるのが理想的です。

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に許可される最大時間を確認します。

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 が 0 以外の場合、 maxtimeをクリックし、それを経過時間と比較します
(上記の例では、14400 の 2/3 は 9600 であり、すべての経過時間の出力はこの図をはるかに下回っています。

さまざまな問題により、GCの実行が遅くなったり、すべてをスキャンできなかったりする可能性があります。これには、過去にかなりの時間または数日間、実行するための十分な時間がなかった、構成が正しくない、エラーなどが含まれます。

懸念がある場合 maxtimeまたはパス回数が指定された場合は、デル・テクノロジーズのAvamarサポート チームでサービス リクエストを作成して 、さらに調査を行ってください。

手順8.GCが十分なデータまたは予想されるデータを削除しなかったと疑われる場合:

GCの実行時間が長いことが確認された場合は、ガベージ コレクションの制御範囲外の理由でデータが収集されていない可能性があります。これは、一般的に確認する必要がある文書化された理由のリストです。

ある。バックアップが少なくとも最終的に、または定期的に期限切れになるように構成されていることを確認します。期限切れのバックアップが頻繁に発生しない場合、GCで行う作業はあまりありません。

b.この記事では、「上位変更率」クライアントを検索します。Avamar：capacity.sh スクリプトを使用して容量を管理する方法。(両方の「% OF TOTAL」と「CHGRATE".)

c. Avamarごとにスキップされたハッシュを確認します。Avamarガベージ コレクションで、クリーンアップできない「skipped-hashes」が報告されます。これらが発生しているがまれな場合、これは正常であり、スキップできます。

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

e.バックアップが最近から切り替えられた場合 GSAN DDバックエンドに移動するか、または偶発的な GSAN バックアップですが、 GSAN 容量が減少しません。Dell Technologies Avamarサポート チームで サービス リクエストを作成し 、さらに調査してください。

ステップ9.Avamarグリッドが、現在追加されるデータまたは追加される予定のデータの量に対して小さすぎます。

他のすべての解決策と考えられる原因が高容量であることを確認し、これが構成の問題または偶発的なデータの問題ではないことを確認したら、次の手順を実行します。

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

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

ある。容量の問題が解決したら、Avamar管理UIですべての容量関連イベントを確認します。

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

dpnctl start sched

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

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

• 通常、この変更またはアクションは実行されないため、デフォルトでは考慮しないでください。Avamar L2エンジニア、またはSME(特定分野エキスパート)がこの変更を承認する必要があります。
• 残念ながら、このようなアクションは、多くの場合、ストレージ ノードの追加または再導入によってのみ解決できるさまざまな方法で、Avamarグリッドに恒久的な損傷を与える可能性があります。

サポート チームは最も有益な方法で容量の問題を解決することを望んでいるため、上記のいずれのアクションも実行されないことを理解してください。