Backup Exec 重複排除用ストレージフォルダのトラブルシューティング

記事: 100039262
最終公開日: 2022-08-02
評価: 0 0
製品: Backup Exec, Appliances

説明

これは、重複排除用ストレージを使用しているときに発生する可能性がある一部の問題とその解決方法、またはベリタステクニカルサポートが問題を迅速に解決する際に役立つ情報の収集方法を示すトラブルシューティングの記事です。

注: Backup Exec 2014、15、16 は、PostgreSQL を重複排除ストレージ フォルダのバックエンド データベースとして利用します。 Backup Exec 20 は PostgreSQL を使用しないため、Backup Exec バージョン 2014、15、16 に適した一部のコマンドは、Backup Exec 20 以降の重複排除ストレージには適用されない場合があります。

 

重複排除用ストレージフォルダの問題:

  1. 重複排除用フォルダがオフラインになっている
  2. 重複排除デバイスが対象の場合にはバックアップが失敗するが、通常のディスクストレージでは正しく動作する
  3. 重複排除デバイスからのリストアが機能しない
  4. 重複排除用ストレージフォルダに空きがない

 

1. 重複排除用フォルダがオフラインになっている

考えられる原因:

重複排除サービスが起動しない、重複排除クレデンシャルが正しくない、重複排除用フォルダが破損している

ディスクが健全であることを確認して、チェックを開始することが重要です。

  1. CHKDSK を実行して、重複排除用フォルダがホストされているドライブが破損していないことを確認します。
  2. Windows インデックスでこのドライブのチェックマークが解除されていることを確認します。
  3. 重複排除用フォルダが作成されているドライブに、ウイルス対策の除外が設定されていることを確認します。

Backup Exec の重複排除用フォルダは、次のいずれかの原因によってオフラインを示すことがあります。

  • 重複排除サービスが起動していない
  • Backup Exec (BE) 内の重複排除用フォルダのクレデンシャルが変更されていて、重複排除 SPA データベース上で更新されない
  • 重複排除用フォルダが破損している

すべての重複排除サービスを起動できることを確認します。Deduplication Engine、Deduplication Manager、Postgres は、すべて、ローカルシステムアカウントで実行されます。いずれかが起動しない場合は、以下のことを確認してください。

  1. レジストリが正しく設定されていないために発生する、PostgreSQL またはその他の重複排除サービスの起動の問題。ImagePath が正確であることを確認します。これを行うには、次のように動作中の別のシステムと比較します (別のシステムが存在する場合)。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\postgresql-8.3 -> ImagePath
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\spoold -> ImagePath
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\spad -> ImagePath
  1. Windows イベントビューアで参照できる、それぞれの重複排除サービスの起動の問題に関するエラーとそれ以外のログ
注意: イベントビューアに表示されるエラーの説明は非常に正確であり、ほとんどの場合に役立ちます。
 
Spoold の起動の問題    - ドライブ:\BackupExecDeduplicationStorageFolder\log\spoold\Spoold.log
Spad の起動の問題      - ドライブ:\BackupExecDeduplicationStorageFolder\log\spad\spad.log
Postgres の起動の問題 - ドライブ: \BackupExecDeduplicationStorageFolder\log\pddb (最新のタイムスタンプログを参照)
                                      ドライブ: \BackupExecDeduplicationStorageFolder\databases\pddb\data\pg_xlog 

Postgres の起動に関する既知の問題:
Program Files\veritas\ または Backup Exec がインストールされているフォルダ内の「Backup」という名前のファイルにより、PostgreSQL サービスの起動の問題が発生し、重複排除用フォルダの作成または再作成時の障害の原因になる場合があります。上記のパスに存在するそのファイルを削除するかそのファイルの名前を変更します。

重複排除サービスの起動:
重複排除エンジンが起動しない場合、さまざまな理由が考えられます。<BE インストールパス>\ spoold.exe --test は Dedupe\etc\Puredisk 内の contentrouter.cfg ファイルをテストするためのものです。このファイルが不正に変更されていると、重複排除エンジンが起動しません (ファイルを修正するにはサポートに連絡してください)。
Dedupe\Data フォルダに bin または bhd ファイルがないと、Backup Exec Deduplication Engine が起動しない場合があります。Data フォルダには、一意のセグメントを格納するすべてのコンテナ (bin と bhd) が含まれています。 https://www.veritas.com/docs/100002421 を参照してください (ウイルス対策によって検疫されたこれらのファイル、ディスクの問題または異常再起動が原因として考えられます)。コンテナの数は、イベントビューア (アプリケーションセクション) に報告されます。重複排除の整合を確保し、重複排除エンジンサービスを起動できるようにするには、ツールを実行する必要があるので、その bin または bhd が見つからない場合は、テクニカルサポートに連絡してください。ツールを実行した後も、将来問題が再発しないように、これらのファイルが消失した根本的な理由を調査することが重要です。一部の根本原因はすでに確認されています (ウイルス対策によるファイルの検疫、ディスクの問題など)。エラーがいつ発生し始めたか、および当日にどのような問題が検出されたかを判定するには、イベントビューアを参照する必要があります。この方法はこれらのファイルが消失した根本原因を判定するのに役立ちます。
  1. サービスが起動した場合も、重複排除のキュー処理が動作していることを確認する必要があります。tlog (dedupe\queue 内) が、2、3 日以上前のものであり、そのまま残っている場合は、内部キュープロセスに何らかの問題がある可能性があります。

本来は自動的にコミットするもので、どのような場合でも誰も削除を行ってはなりません (tlog ファイルを手動で削除すると、重複排除用フォルダとバックアップセットに悪影響を与える可能性があります)。

注意: キュープロセスのエラーは Dedupe\log\spoold\storaged.log に記録されます。
https://www.veritas.com/docs/100028608 を参照してください。- キュー処理が実行されない既知のケース

キュー処理を手動でトリガするには、コマンドプロンプトから crcontrol.exe --processqueue を実行して (BE インストールパスから実行。コマンドは 2 回実行) キューフォルダ内の tlog がクリアされているかを確認します。 
注意: 最新のエントリは末尾に追加されるため、ログは終わりから確認してください。
依然として「Stroraged.log」でエラーが報告されている場合は、ベリタステクニカルサポートに問い合わせてください。

  1. 重複排除用フォルダがまだオフラインになっていて、すべての重複排除サービスが実行されている場合は、Backup Exec サービスを再起動します。それでも重複排除用フォルダがオフライン状態のままの場合は、<Backup Exec インストールパス>\logs フォルダ内にある「adamm.log」を参照してください。下から adamm.log を確認します。

例: 以下の adamm ログの抜粋を参照してください。この場合、重複排除ユーザーのパスワードが正しく更新されていません。
Backup Exec 重複排除資格情報とその使用方法を参照してください。

次に、adamm.log で類似のセクションを検索する方法を示します。

  • adamm.log を開く。
  • ページの下部に移動する。
  • 文字列「adamm log started」を検索する。
  • 見つかった場合は、そこからログを読み始める。次のセクションを確認し、エラーを記録する。

[04596] 02/24/16 03:09:24.300 Read OST Server Records - start 
[04596] 02/24/16 03:09:24.345 OST Server: PureDisk:BE-CAS:PureDiskVolume
[04596] 02/24/16 03:09:24.345 Read OST Server Records - end
[04596] 02/24/16 03:09:24.345 DeviceIo Discovery - start
[04596] 02/24/16 03:09:26.431 DeviceIo: STS: Critical: (Storage server: PureDisk:BE-CAS) PdvfsRegisterOST: Failed to register with SPA on storage server BE-CAS. Check to make sure the server is on and that the services are running. (Permission denied) V-454-25
[04596] 02/24/16 03:09:26.432 DeviceIo: sts_open_server PureDisk:BE-CAS dedup 2060029
[04596] 02/24/16 03:09:26.432 DeviceIo: ostaspi: sts_open_server PureDisk:BE-CAS as dedup error 2060029
[04596] 02/24/16 03:09:26.432 DeviceIo: ostaspi: authorization with server PureDisk:BE-CAS has failed

「SGMON.exe」を使用して、重複排除用フォルダのオフラインの問題をデバッグすることもできます。すべての重複排除関連サービスが問題なく起動したら、Backup Exec サービスのみをシャットダウンし、デバイスおよびメディアの詳細を有効にした状態で「SGMON」を起動して (詳細は SGMON 設定から有効にできます)、すべての Backup Exec サービスを起動します。
注意: SGMON.exe は Backup Exec インストールパスにあります。

次のように SGMON または文字列「ERR」が含まれている他のすべてのログをフィルタ処理します。SGMON ログファイルの名前が異なる場合があるので、ログの場所をチェックしてログファイルの名前を確認します。

C:\Program Files\veritas\Backup Exec\Logs>findstr /C:"ERR" BE-CAS-SGMon.log > SGMON_ERR.log

PVLSVR:   [02/24/16 03:18:32] [2436]     DeviceIo: STS: Error: [ERROR] PDSTS: pd_register: PdvfsRegisterOST(BE-CAS) failed (13:Permission denied)
PVLSVR:   [02/24/16 03:18:32] [2436]     DeviceIo: STS: Error: [ERROR] PDSTS: add_mount: PdvfsMount() failed for mount point:<BE-CAS#1> (13:Permission denied)
PVLSVR:   [02/24/16 03:18:32] [2436]     DeviceIo: STS: Error: [ERROR] PDSTS: open_server: pd_mount() failed (2060029:authorization failure)
PVLSVR:   [02/24/16 03:18:32] [2436]     DeviceIo: STS: Error: [ERROR] PDSTS: impl_open_server: open_server(PureDisk:BE-CAS) failed (2060029:authorization failure)
PVLSVR:   [02/24/16 03:18:32] [2436]     DeviceIo: STS: Error: [ERROR] PDSTS: pi_open_server_v7: impl_open_server(PureDisk:BE-CAS) failed (2060029:authorization failure)

サービスが起動されていても重複排除サービスがオフラインになる場合、複数の理由が考えられます。したがってこれは、単に 1 つの例です。1 つ注意が必要なのは、UI から重複排除用フォルダを削除して再インポートしても、上記の理由により重複排除用フォルダをオンラインにすることはできないということです。

注意: Backup Exec で重複排除用ストレージフォルダを作成または再インポートしているときにエラーが表示された場合は、「pdde-config.log」を参照する必要があります。ログファイルは DedupeFolder\log 内にあります。
「重複排除フォルダの作成または再作成が失敗し、「重複排除用ストレージフォルダの作成時にエラーが発生しました」というメッセージが表示される」を参照してください。

「EtcPath」および「ConfigFilePath」の文字列の値を次の Windows レジストリの場所から削除することが必要になる場合があります。
HKEY_LOCAL_MACHINE\SOFTWARE\veritas\PureDisk\Agent。
注意: これは再インポートの場合にのみ適用されます。
Windows レジストリエディタを正しく使用しないと、オペレーティングシステムが正しく機能しなくなる場合があります。Windows レジストリを変更する場合は十分に注意してください。レジストリの変更は、レジストリエディタの操作に精通しているユーザーのみが行うようにしてください。レジストリの変更を行う前に、レジストリとワークステーションの完全なバックアップを行うことをお勧めします。

  1. Backup Exec 2014 にアップグレードすると、Deduplication Manager (SPAD) が起動時にクラッシュする場合があります。


2. 重複排除デバイスが対象の場合にはバックアップが失敗するが、通常のディスクストレージでは正しく動作する

重複排除用フォルダが対象の場合にのみバックアップの問題が発生する場合は、問題を絞り込むことが重要です。バックアップしようとしているリソースの種類、または重複排除用ストレージ以外の、バックアップに影響する他の何らかの要素が原因として考えられ、重複排除内の何らかの要因が関係している場合もあります。
 

  1. 重複排除用フォルダがオンラインになると、バックアップがキューに投入される。 
既知の理由の 1 つが次の記事に記載されています。 https://www.veritas.com/docs/100007231。他の原因として、バックアップを実行する Backup Exec が使用できない障害があるメディアの存在が挙げられます。インベントリを実行して、すべての OST メディアが読み込み可能であることを確認します。

その他の不一致の可能性もあります。別の問題 https://www.veritas.com/docs/100028903 を参照してください。

  1. 重複排除へのバックアップを実行できず、アクティブなジョブが存在しない場合でも「準備完了;アイドルデバイスがありません」というステータスが表示される。
すべての Backup Exec と重複排除サービスを再起動します。重複排除デバイス上でバックアップが実行されていないときに \\.pdvfs\servername\2\BEOST\BEOST_SDrv\ が空であることを確認します。ドライブのマウントが解除されない場合は、回避策として重複排除の同時並行処理数を増やすことができますが、この問題が再発した場合は、ベリタステクニカルサポートに連絡して、問題のチェックを行ってください。

注意: 上記のパスでは何も削除したり操作したりしないでください。単にコンテンツを表示して、論理ドライブが存在していれば、Backup Exec サービスを再起動してそのドライブのマウント解除を試行します。パス内のサーバー名は、重複排除用フォルダが存在するサーバーのホスト名に置き換える必要があります。

  1. クライアント側のバックアップに失敗し、読み取り書き込みエラーが表示される。
メディアサーバー側の重複排除を使用するバックアップをテストして、バックアップジョブが引き続き失敗するかどうかをチェックできます。メディアサーバー側の重複排除が動作する場合は、ネットワーク上の問題 (つまり、クライアントと BE サーバー間の問題) が原因となってこれらのエラーが発生している可能性があります。ただし、これは唯一の原因とはいえません。したがって、クライアント側とメディアサーバー側の両方の重複排除バックアップをテストします。クライアント側とメディアサーバー側で選択する設定を編集するには、[バックアップジョブ] -> [編集] -> [ストレージ]セクションの順に選択します。

Backup Exec サーバーで、次のレジストリパスに「KeepAliveTime」(dword) を作成して、10 進値の 5000 に設定し、効果があるかどうかをテストできます。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

(注意: サーバーを再起動する必要があります)

クライアント側のバックアップにまだ失敗する場合は、Job Engine、Backup Exec Server、デバイスおよびメディアを選択した状態で (設定から、デバイスおよびメディア用の詳細を選択) SGMON ログをバックアップの実行時にキャプチャできます。また、クライアントサーバーから SGMON ログを取得します。ログの詳細について詳しくは、https://www.veritas.com/docs/100001042 を参照してください。

ベリタステクニカルサポートスタッフが分析用に収集することもできる追加のログが、DedupeLocation\log\spoold\remoteclientserver\beremote\store に作成されます。

上記のログの場所は、リモートサーバーとそのプロセス (Beremote プロセス) に接続する spoold として解釈できます。その Beremote によって、重複排除サーバーとのストア接続バックアップなどが行われます。この内部のログを参照して接続が中断された場合の接続リセットエラーを検索できます。ウイルス対策ソフトウェアがこのような中断の原因になっている場合があります。したがって、この問題を分離するために、可能な場合はウイルス対策ソフトウェアをアンインストールして、その状況を確認します。ウイルス対策アプリケーションを無効にしても意味がないという意見もありますが、ウイルス対策ソフトウェアをアンインストールしてテストすることをお勧めします (注意: これはソリューションではありませんが、問題を分離する際に役立ちます)。

  1. ネットワークの問題によって、この読み取り書き込みエラーが発生し、バックアップサーバーまたは LSU 間の最適化された複製に失敗する場合がある。https://www.veritas.com/docs/100031866 を参照してください。

SGMON.exe は、Backup Exec で多くの問題のデバッグに役立つユーティリティです。最適化された複製が実行されているときに、SGMON を使用してこの問題をデバッグできます。これは、最適化された複製操作を実行している Backup Exec サーバー上で行う必要があります。
また、「DedupeFolderlocation\log\spad」の replication.log を (プライマリ重複排除バックアップ (1 番目のコピー)) で参照してください。最適化された複製の対象になるターゲット側で、「DedupeDrive:\log\spoold\primarydedupeBEservername\spad.exe\Store\」をチェックして、最大サイズのログを目安として確認してください。

詳しくは、Windows イベントビューアと Backup Exec サーバーの ADAMM のログも確認してください。

ハードウェア OST アプライアンス間の最適化された複製では、問題を絞り込むために、最適化された複製の障害発生時の SGMON とベンダーの OST プラグインのログが必要になります。

  1. このジョブ用にクライアント側の重複排除が有効になっているが、それを使用できない。https://www.veritas.com/docs/100022683 <BE インストールパス>\logs の adamm.log を確認します。そのログを開き、下から上へと検索して文字列「DeviceIo Discovery - start」が見つかったら下へと移動します。クライアント側の例外確認されたリモートサーバーの場合は、そこで報告されているエラーについてチェックしてください。例: [08792] 04/21/16 09:26:51.801 DeviceIo: Discover: configure remote OST server PureDisk:BE-CAS for dbclient1.lab.symc failed, error=7. このエラーについての詳細は、コマンドプロンプトで net helpmsg 7 を実行して確認できます。このエラーはストレージの制御ブロックが破損していることを示しています。これは、Backup Exec リモートエージェントが重複排除エンジンおよび重複排除マネージャサービスポートとの間で試行される接続が、DNS または任意のファイアウォールによって中断されることに関連する可能性があります。ファイアウォール規則の更新、または他のそれぞれのサーバーのホストファイルの正しい IP とホスト名エントリの更新 (クライアント側が動作していない BE およびリモート サーバー) によって、接続に成功する場合があります。修正変更を行った後は、Backup Exec デバイスとメディアサービスを再起動して、変更後に同じクライアントで同じエラーが表示されないかどうかを、adamm.log で再チェックすることが重要です。リモートクライアントのエラーが表示されなくなったら、クライアント側のバックアップを再度テストします。
     
  2. クライアント側重複排除バックアップまたは 最適化された複製 (opt-dupe) ジョブを使用する場合は、常に検証を別のジョブとして実行されるようにしてください。 重複排除フォルダーをホストする BE サーバーでローカルに実行されます。 Backup Exec ジョブの編集 -> 検証 -> [ジョブが完了した後に個別のジョブとして実行] または [別のスケジュールジョブとして] を選択します。



3.重複排除用フォルダからのリストアが機能しない

  1. バックアップセットを検証することが重要です。検証を行うには、重複排除ストア内から[Backup Exec コンソール] -> [ストレージ] -> [重複排除用フォルダの詳細] -> [バックアップセット] の順に選択して、リストアするバックアップセットを選択し、右クリックして[検証]を選択します。
    1. 検証ジョブが失敗した場合: そのバックアップセットに問題がある可能性があります。その場合は、バックアップがそのリソースで成功したかどうかをチェックする必要があります。
    2. 検証ジョブが成功した場合: 通常のディスクストレージ (B2D) にバックアップセットを複製し、リストアをテストします。
  2. これが特定のバックアップセットの問題の場合は、同じリソースの他のバックアップセットからリストアをテストして、問題を絞り込みます。
  3. 通常のディスクに対して同じリソースのバックアップを実行して (つまり B2D への新しいバックアップ)、リストアのテストを実行します。
注意: 状況によっては、Backup Exec のクレデンシャルの問題の絞り込みに役立つ場合があります。
  1. もう 1 つのテストの方法として、重複排除用フォルダのプロパティからクライアント側の重複排除を無効にできます。無効化するには、[Backup Exec コンソール] -> [ストレージ]の順に選択します (この場合もテストして問題を絞り込み、回避策を実行することが唯一の目的です)。これを行うと、Backup Exec サービスを再起動するよう求められます。サービスが再起動されたら、リストアを試行して状況を確認します。解決しない場合は、ベリタステクニカルサポートに連絡してさらに調査してください。



4. 重複排除用ストレージフォルダに空きがない

a. 重複排除デバイスが容量満杯の状態に近づいているかどうかをチェックします。
Backup Exec コンソールの[ストレージ]タブの容量列にディスクストレージの使用状況が表示されます。色が赤の場合は、重複排除デバイスが容量満杯の状態に近づいていることを示すアラームです。
注意: 95% の使用状況は重複排除用フォルダで確認されている最高値です。この時点で、新しいバックアップを実行できるように、重複排除用ストレージ内の領域を再利用する必要があります。「Backup Exec 以外の操作用に予約するディスク容量の割合」値を 5% 未満にしないようにすることをお勧めします。

b. 重複排除の統計情報をチェックします。
コマンドプロンプトで、<BE インストールパス> から次のコマンドを実行して、実際の重複排除統計情報を確認できます。

crstats.exe --verbose --convert-size (重複排除用ストレージフォルダをホストする Backup Exec メディアサーバー上の Backup Exec インストールパスから実行)

参照する必要があるパラメータは次のとおりです。
  • Use Rate - 95 未満になっている必要があります。重複排除の領域について不安を抱かずに実行できるよう、70 から 80 パーセントの範囲に抑えることが望まれます。
  • Catalog Logical Size - これは重複排除用フォルダに存在しているフロンドエンドデータ (つまり元のサイズの非圧縮データ) を表します。
  • Space Allocated For Containers - これは重複排除コンテナが占有する領域です。Dedupe\data フォルダ内のコンテンツを表します。
  • Space Used Within Containers - この値がコンテナに割り当てられた領域にほぼ近づくと、領域がさらに必要になるため、新たなバックアップ (さらに一意のデータをバックアップする場合) 用に新しいコンテナが作成されます。この時点で使用率が高く、コンテナ内に利用可能な領域がない場合は、重複排除ディスクボリュームを拡張するか、既存のバックアップセットを削除して領域を再利用することが必要になる可能性があります。
  • Space Available Within Containers - 重複排除データフォルダ内のそれぞれのコンテナの容量は 256 MB です。コンテナによっては完全に満杯になる可能性があります。すべてのコンテナを含めて残っている領域は、コンテナ内の利用可能領域と呼ばれます。コンテナ内に十分な領域があるとバックアップを実行できますが、使用率については再度注意する必要があります。
  • Space Need Compaction - これはコンテナ内で使用されている領域内から削除または参照解除された領域ですが、重複排除コンテナ内の領域を占有しています (つまり、Dedupe\data 内の bin と bhd)。これは使用済みの割合を計算するときはカウントされませんが、TB レベル (高) になっている場合は、crcontrol.exe --compactstart 100 0 1 を実行してください (コマンドプロンプトで、<BE インストールパス>\ から実行します。このコマンドは完了するまでしばらく時間がかかる場合があります)。 常に管理者特権モードでコマンドプロンプトを開きます。ステータスを監視するには、crcontrol.exe --dsstat を実行して重複排除用フォルダの統計情報を監視することもできます。

c. 手動による領域の再利用:
領域を再利用する必要がある場合は、この技術情報 Backup Exec で重複排除ストレージまたは重複排除対応クラウドストレージ領域の回復する方法とタイミングに従ってください。

注意: 重複排除用フォルダ内の領域の手動による再利用を試行するときは、バックアップ (例えば別のストレージへのバックアップ) を停止することをお勧めします。これは、再利用プロセスの実行時にバックアップを続行すると、データが常に追加されるため再利用されている領域の容量を特定することが困難になる可能性があるためです。

 


重複排除用ストレージから手動で領域を再利用するときの重要ポイント:

  1. 重複排除統計から、重複排除率を確認します。高い場合、つまり著しい重複排除率になっている場合は、一部の領域を解放するためにさらにセットを期限切れにすることが必要になる場合があります。これは、重複排除では、チャンクの最後の参照がなくなるまでそのチャンクに必要な領域が解放されないためです。(詳細について詳しくは、再利用の article を参照してください)
  2. Backup Exec コンソールから手動でバックアップセットを期限切れにすると、コア BE サービスによって、そのバックアップセットのメディアとカタログ参照が BE 内から削除されます (BEDB、カタログなど)。この活動は BE 監査ログに記録されます (Backup Exec コンソールに戻り、[構成と設定 - 監査ログ]を選択し、ドロップダウンから[バックアップセットの保持]カテゴリを選択して、そのバックアップに使用されたメディアが削除されているかどうかをチェックします)。バックアップセットによって使用されたメディアの特定方法については、記事番号 100032128 の解決策を参照してください。
  3. 100032128 によって解決される場合は (解決されない場合は、テクニカルサポートに連絡してください)、BE Deduplication Manager に、これらのメディア参照を重複排除用フォルダ内から削除する必要があることが通知されます。Deduplication Manager は、役割を Deduplication Engine Service に委任し、これらの参照と更新が Deduplication Engine データベースから削除されるようにします (重複排除エンジンを更新するために、データベースの tlog が作成されます。tlog は実際に重複排除データベースの更新を実行するための方法です)。tlog をコミットするには、キュー処理 (手動再要求の article に記載) を数回実行する必要があります。そのときに、重複排除統計情報をチェックして、使用率を下げるためにさらにバックアップセットを期限切れにするかどうかを判断する必要があります。
  4. 手動再利用プロセスを実行した後は、コンテナ内の使用可能な領域が増えます。領域ニーズの圧縮も、このプロセスの後に高くなる可能性があります。 crcontrol.exe --compactstart 100 0 1 を実行すると、コンテナ内の使用可能領域と領域ニーズの圧縮がファイルシステムに提供されます。このコマンドは数回実行することが必要になる場合があります (コマンドプロンプトを使用し、BE インストールパスから実行します)

 

重複排除率が期待値よりも低い:

ジョブ ログ内に重複排除率が表示されます。この例では 72.9% です。

Deduplication Stats::PDDO Stats for (Servername): scanned: 543241 KB, CR sent: 147034 KB, CR sent over FC: 0 KB, dedup: 72.9%
 
重複排除率が予想よりも小さい場合、バックアップの種類 (VMwareかリモート エージェントバックアップ)、データ自体がファイルシステムデータ、データベース、または仮想マシン (VM) かなど、複数の根本原因が考えられます。特定のタイプのバックアップまたはデータのタイプに関連しているかどうかを特定する前に、問題がすべてのバックアップ ジョブに存在するのか、それともいくつかのジョブにのみ存在するのかを明確にします。

 
すべてのバックアップ ジョブに影響する場合は、より一般的な問題である可能性が高いため、次の手順に従ってください:
 
a) DCSCAN
DCSCAN を使用して、重複排除ストレージ フォルダー全体の内容を検証します。
DCSCAN の詳細については、https://www.veritas.com/docs/100006521 を参照してください。
 
コマンドラインは次ようになります

  • cd "\Program Files\veritas\Backup Exec"
  • crcontrol --compactoff      (注: compactoff の前はハイフンが2つです)
  • dcscan --verify -q -H -a > crcerrors.txt 2>&1       (注: verify の前はハイフンが2つです)
  • crcontrol --compacton       (注: compacton の前はハイフンが2つです)

crcerrors.txt ファイルが 0 バイトの場合、dcscan プログラムは重複排除フォルダー内で破損を検出しませんでした
crcerrors.txt ファイルでエラーが報告された場合は、報告されたエラーの調査を開始します。

 

可能性のあるエラーと対策:

25017: FileCopyA: could not open destination file D:\Dedupe\data/journal/delstat_0.log

これは delstat.log での問題です。詳細と解決策は https://www.veritas.com/docs/100032504 を参照してください。

 

重要:

  • ベリタステクニカルサポートによって確認されていない限り、重複排除用ストレージフォルダ内からファイルを削除しないでください
  • Backup Exec 2014/15/16 は重複排除バージョン 7 を使用します 。以前のバージョンよりも高速かつ円滑に実行できます。
  • Backup Exec 20 は重複排除バージョン 10 を使用します。これは、古い重複排除バージョン 7 よりも、より優れています。
  • Backup Exec 20 へのアップグレードには、重複排除ストレージの大幅な変換が含まれます。 PostgreSQL サービスが削除され、重複排除ストレージ フォルダーは新しい重複排除バージョンの形式に変換されます。

UMI Code: V-275-550

Was this content helpful?