Avamar：オペレーティング システム(OS)の容量(解決パス)

概要: この解決パスの記事では、Avamarのオペレーティング システム(OS)容量の問題を処理またはトラブルシューティングします。

この記事は次に適用されます： この記事は次には適用されません： この記事は、特定の製品に関連付けられていません。 すべての製品パージョンがこの記事に記載されているわけではありません。
他のリソースを確認する

現象

Avamar.

でOS容量の問題を処理またはトラブルシューティングする方法この解決パスの記事は、Avamar.


のOS容量の問題に対処またはトラブルシューティングすることを目的としています。OS容量の初期概念と理解については、トレーニング記事「 Avamar: 容量管理の概念とトレーニング

トレーニング記事から要約されているように、この記事の残りの部分を進めるには、次のトピックを合理的に理解する必要があります。

  • チェックポイント(cp)、チェックポイント検証(hfscheck)、ガベージ コレクション (GC)、およびそれぞれの重要性
  • 違いは GSAN (別名「ユーザー容量」および「OS容量」)
  • チェックポイントのオーバーヘッド データ
  • いずれかのデータ パーティションが物理OS容量の合計領域の89%を超えている場合、ガベージ コレクションは実行できません。
  • Avamarグリッドが100%のユーザー容量に近づくほど、チェックポイントのオーバーヘッドに使用できるOS容量は少なくなります。
  • 非同期処理、格納されているチェックポイントの数、チェックポイントのオーバーヘッドに寄与する要因 HFSCheck チェックポイント検証の重要性など。
  • OSの容量レベルを確認する方法
  • OS容量を軽減するための基本的なアクション

 

多くの場合、OS容量を GSAN データ(具体的には、このデータに割り当てられた領域)と、Avamarチェックポイントによって生成されるオーバーヘッド。チェックポイントの数が多く、変更率が高いほど、チェックポイントのオーバーヘッドは高くなります。


OSの容量が大きいと、次のような影響が考えられます。

  • ガベージ コレクションの失敗: MSG_ERR_DISKFULLでGCが失敗する OS容量が89%を超えた場合
  • バックアップまたはレプリケーションの失敗: OS容量が90%を超えると、MSG_ERR_STRIPECREATEでバックアップまたは受信レプリケーションが失敗することがあります。(これは、新しいデータ ストライプを作成する必要がある場合にのみ行われます。新しいストライプが不要な場合でも、バックアップとレプリケーションは正常に実行できます)。
  • チェックポイントの失敗: OS容量が96%を超えると、MSG_ERR_DISKFULLでチェックポイントが失敗する


前述のように、多くの場合、OS容量は、他のAvamar容量が高い場合に対応する最初のAvamar容量タイプです。少なくとも、OS容量が特定のレベルに達した場合、ガベージ コレクションは実行できません。 GSAN またはユーザー容量も大きくなります

一般に、OS容量が89%を超えると、MSG_ERR_DISKFULLでGCに障害が発生すると、OS容量が高いと見なされます。OS容量が89%未満の場合、メンテナンス ジョブは影響を受けません。 

 
注：OS容量は一日を通して変動することが予想されます。日常のメンテナンス ジョブがスムーズに実行されていることを確認することは重要であり、可能な限りOS容量の問題を回避するための最善の解決策です。
 
注：上記はAvamar OSの容量と見なされますが、バックアップ パーティションまたはチェックポイントに直接関連しないOS容量の問題が発生している可能性があります。これらは、Linux OSがインストールされているディスクとパーティションです。これらの問題はあまり一般的ではありませんが、以下で説明する他の影響を与える可能性があります。

原因

Avamar OSの容量は、次の理由が組み合わさって増加する場合があります。

  • バックアップ データの変更率が高く、「多すぎる」速すぎる
  • High GSAN または「ユーザー容量」:OS容量の余地が少なくなり、変更率が高くなる場合もあります
  • チェックポイントが正常に完了せず、出力に「MSG_ERR_DISKFULL」のステータスが表示されます。
  • チェックポイント検証 (hfscheck) が失敗したか、最近実行されていないため、最も古いチェックポイントをロールオフまたは削除できない
  • チェックポイントの保存期間設定が高すぎるなど、他の理由でチェックポイントがロール オフされない
 

他のディスク パーティションのOS容量の増加は、誤ったデータ配置、ログ ファイルが大きくなりすぎるなど、さまざまな原因で発生する可能性があります。

 
OSの容量が大きくなる理由として「速すぎる」というフレーズを簡単に説明すると、次のようになります。
  • 簡単に説明すると、Avamarチェックポイントは読み取り専用のスナップショットであり、ライブ データへのリンクです。これはリンクを使用して作成されるため、チェックポイントは作成直後から余計なディスク領域を使用しません。ライブ データに変更がない場合、チェックポイントは追加の領域を使用しません。
  • これは、チェックポイントが同じままでライブデータが変更されると変化します。その時点で、チェックポイント内のデータのオリジナル コピーと、変更されたデータの更新されたライブ コピーが存在します。これは完全に意図的なものです。これが、予約されたOS容量スペースがある理由です。
  • ただし、データの変更量または変化率が急激かつ急激に増加すると、OSの容量サイズが通常とは異なるほど急増し、「速すぎる」と見なされる可能性があります。
  • 「 capacity.sh ツールでは、数日間にわたる出力を比較すると、これが原因として表示されます。

解決方法

Avamar OSの容量が大きいために、ガベージ コレクションを含むメンテナンス ジョブが失敗する場合は、次の手順に従います。

1.すべてのAvamar容量情報を収集して、状況を把握します。Avamar：容量の問題のトラブルシューティングに必要な情報を収集する方法。


2.次に、OSの容量と必要なアクションを確認します。これは、データ コレクションの記事から、次のコマンドを使用して見つけることができます。 

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

Avamarの仕組みでは、表示されているfs-percent-fullの最大値が現在のOS容量の制限要因になります。ノード タイプの世代とサイズに応じて、バックアップ データとチェックポイント データを格納するデータ パーティションの数が異なる場合があります。Linuxオペレーティング システムから認識される場合、これらは「/data0*」のようなディスクまたはパーティションである可能性があります。ここで、「*」は1桁の数字にすることができます。データ パーティションの数は、ノード タイプ、ハードウェアの世代、サイズによって異なります(変更できません)。


3.コマンドから、検出されたチェックポイントの数と、それらが最近どの程度検証されたかを確認します。

cplist
cp.20290310080041 Mon Mar 10 08:00:41 2025   valid rol ---  nodes   4/4 stripes   5980
cp.20290310080649 Mon Mar 10 08:06:49 2025   valid --- ---  nodes   4/4 stripes   5980
 
注： 一部のチェックポイントは、ALWAYを保持する必要があります。
 
 

4.次のコマンドを実行して、チェックポイント操作が「MSG_ERR_DISKFULL」から失敗しているかどうかを確認します。

dumpmaintlogs --types=cp --days=4 | grep "\<430"


チェックポイントが正常に完了すると、次のような出力が表示されます。

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> completed checkpoint maintenance
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance


MSG_ERR_DISKFULLが原因で失敗した場合は、次の出力が表示されます。

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance
 
チェックポイント操作がMSG_ERR_DISKFULLエラーで失敗する場合は、Dell Technologies Avamarサポート チームで サービス リクエストを開きます 。それ以外の場合は、手順5から続行します。
 
 
5.他のチェックポイントの問題があるかどうかを確認します。
 
「 cplist commと 検出されたチェックポイントの数と、チェックポイントが最後に検証された時間を表示します。データ収集に関する記事にも示されているように、「 Avamar:cplistコマンドによって生成された出力を理解する方法」を使用して、 cplist output.

2つまたは3つのチェックポイントがあり、過去24時間のチェックポイントの少なくとも1つが検証済みとして表示されます hfscheckの詳細を確認してください。これは正常な動作であり、正常に実行されているすべてのジョブと通常のチェックポイント保存設定からの出力です。

3つ以上のチェックポイントがある場合、または過去24時間以内に検証済みのチェックポイントがない場合は、最初にこれに対処する必要があります。これがOS容量を削減する唯一の方法である可能性があるためです。このシナリオが発生した場合は、デル・テクノロジーズで サービス リクエストを開きます 。それ以外の場合は、手順6から続行します。
 
 

6.変更率を決定します。

capacity.sh

 

出力例:

  DATE     AVAMAR NEW     #BU    SCANNED       REMOVED     MINS PASS AVAMAR NET      CHG RATE
========== ============= ==== ============= =============  ==== ==== ============= ==========
2020-02-25       1066 mb    8     302746 mb       -641 mb     0   23        425 mb      0.35%
2020-02-26       1708 mb    8     303063 mb       -518 mb     0   23       1189 mb      0.56%
2020-02-27       3592 mb    8     304360 mb       -413 mb     0   23       3178 mb      1.18%
2020-02-28       1086 mb    8     304892 mb       -372 mb     0   23        713 mb      0.36%
2020-03-01       1002 mb    8     305007 mb      -7469 mb     0   25      -6467 mb      0.33%
2020-03-02        585 mb    7     197874 mb          0 mb     0    9        585 mb      0.30%
2020-03-03        348 mb    7     199305 mb          0 mb     0   10        348 mb      0.17%
2020-03-04        775 mb    7     198834 mb         -2 mb     0   10        773 mb      0.39%
2020-03-05        380 mb    4     196394 mb         -5 mb     0   10        375 mb      0.19%
2020-03-06       1068 mb    4     159960 mb          0 mb     0    9       1067 mb      0.67%
2020-03-07        443 mb    4     197132 mb        -18 mb     0   17        424 mb      0.23%
2020-03-08        348 mb    4     197231 mb        -48 mb     0   20        300 mb      0.18%
2020-03-09        370 mb    4     196506 mb          0 mb     0    9        370 mb      0.19%
2020-03-10        349 mb    4     197292 mb        -17 mb     0   20        332 mb      0.18%
2020-03-11        974 mb    2      77159 mb          0 mb     0    0        974 mb      1.26%
=============================================================================================
 14 DAY AVG       940 mb    5     222517 mb       -634 mb     0   15        306 mb      0.42%
 30 DAY AVG      1121 mb    5     195658 mb       -771 mb     0   14        349 mb      0.59%
 60 DAY AVG       994 mb    4     128657 mb      -1165 mb     0   17       -170 mb      0.98%

Top Change Rate Clients.  Total Data Added 14103mb

     NEW DATA % OF TOTAL CHGRATE TYPE CLIENT
============= ========== ======= ====
      6803 mb     48.24   0.91%  AVA /Windows/testing/Hyper-V/hyperv1
      3218 mb     22.82   0.61%  AVA /clients/exchange1
      2932 mb     20.80   0.44%  AVA /BMR/server1
       983 mb      6.97   0.10%  AVA /Windows/testing/SQL/sql1
        97 mb      0.69   1.13%  AVA /REPLICATE/grid2.company.com/MC_BACKUPS

 


変更率が高い場合や「速すぎる」状況が再発する場合は、全体的な GSAN またはユーザー容量。下部の GSAN 容量については、OS容量のオーバーヘッドの余地が少し増え、データ ストレージ コンテナの変更も少なくなります。このシナリオのサポートが必要な場合は、Dell Technologies Avamarサポート チームで サービス リクエストを開きます 。それ以外の場合は、手順7から続行します。

 

7.他のディスク パーティション上の高 OS 容量の問題にはさまざまな原因がありますが、解決策にはテクニカル サポートが必要です。Dell Technologies Avamarサポート チームでサービス リクエストを開きます。それ以外の場合は、手順7から続行します。

 
 

OS容量に対応したら、 GSAN 容量またはその他のAvamar容量を確認できます。「 Avamar容量のトラブルシューティング、問題、質問 - すべての容量(解決パス)」を参照してください。

 

対象製品

Avamar, Avamar Server
文書のプロパティ
文書番号: 000169014
文書の種類: Solution
最終更新: 12 3月 2025
バージョン:  7
質問に対する他のDellユーザーからの回答を見つける
サポート サービス
お使いのデバイスがサポート サービスの対象かどうかを確認してください。