NetWorker:メディア データベースのメンテナンスとトラブルシューティング
概要: この記事では、メディア データベースに関連する問題を特定して処理する方法と、メンテナンスと保護のベスト プラクティスについて説明します。
現象
- サービス開始の失敗。
- 毎日のサーバー保護>サーバー バックアップ ワークフローの失敗。
- セーブセットまたはクライアントに関連する不完全または誤解を招く情報
mminfoコマンドを使用するか、NMC(NetWorker管理コンソール)またはNWUI(NetWorker Webユーザー インターフェイス)管理でセーブセットをクエリーまたは参照する場合に使用します。 - セーブセット、クライアント、またはボリュームを特定できないことに関連したバックアップ、リカバリー、またはクローン作成の問題。
- メディア データベースに関連するサーバー デーモン ログまたはコンソールのエラー:
nsrmmdbd WiSS code assertion error (st_nextrec: rec loop detected)
nsrmmdbd error, ss_clone_ensure_clone_eligibility: assertion, invalid parameters or code segment
nsrmmdbd XCHK ssid:saveset_short_ssid host:saveset_hostname name:saveset_name has a fragment with an invalid volid:saveset_volid
nsrmmdbd NSR warning WiSS code assertion error (ST_readvdir: directory read failed)
nsrmmdbd NSR critical Unexpected error reading long record directory: an invalid slot number
nsrmmdbd NSR warning partial record error, ssid: saveset_short_ssid saveset_long_ssid flags:0x00010101 size:0 files:0 tm:datetime cloneid
nsrmmdbd NSR notice media db must be scavenged
nsrmmdbd NSR critical media db scavenge failed
nsrmmdbd NSR warning Cannot scavenge path_to_mmvolume6 (Permission denied) - recover from backup media
nsrmmdbd NSR warning Cannot scavenge path_to_mmvolume6 (unknown error code) - recover from backup media
nsrmmdbd MDB warning can't fetch save set <saveset ID>
nsrmmdbd MDB warning Unable to fetch child save set <saveset ID> for cover set <saveset ID>
- メディア データベースから多数のセーブ セットが突然失われた、または使用可能なディスク ストレージの空き領域が突然急増した。
- ソフトウェアがセーブセットを期限切れにしたり削除したりできず、ストレージが急速に消費される。
原因
他のデータベースと同様に、メディア データベースは、次のような通常のオペレーションに何らかの推論がある場合、程度の差こそあれ損傷を受ける可能性があります。
- 次の予期しないシャットダウン
nsrmmdbdプロセス(コア ダンプ、システム クラッシュ、再起動、電源喪失)。 - トランザクションの中断(外部セキュリティ ソフトウェアの干渉またはディスク領域の枯渇)。
- 論理内部の問題(コードの欠陥または未処理の状態)。
- NetWorkerが管理するストレージ上のメディア データベース ファイルまたはセーブセット ファイルとの直接干渉。
メディア データベースを損傷から保護するには、次の一般的な方法を使用します。
- 可能であれば、別のローカル ディスク パーティションを使用します。
/nsr/mmフォルダーは、他のプロセスによるディスク容量の枯渇などの状態から保護するのに役立ちます。このパーティションは、メディア データベースのサイズの少なくとも3倍にする必要があります。大規模なメディア データベースは10 GBです。どのようなインストールでも100 GBで十分です。 - 災害発生時にメディア データベースと重要なディザスター リカバリー リソース( ブートストラップ)のバックアップを使用できるように、サーバー バックアップ ワークフローが毎日完了していることを確認します。
- を使用してブートストラップの場所を確認します。
mminfo -Bコマンドを定期的に実行します。 - データ ロスにつながる可能性があるため、別のNetWorkerサーバーがNetWorkerサーバーのストレージ ボリュームに同時にアクセスしないようにします。
- NetWorkerサーバーにウイルス対策ソフトウェアがインストールされている場合は、
/nsrディレクトリーに設定して、アンチウイルス ソフトウェアによるNetWorkerファイルのスキャン、変更、削除を防止します。 - 領域を解放するために、NetWorkerストレージ内のファイルを手動で削除しないようにします。NetWorkerには、毎日実行されるスペース再利用ルーチンがあり、これらが失敗していると考えられる場合は、サポートに連絡する必要があります。
- 一般に、データ ゾーンのプランニングでは、必要に応じてメンテナンスを容易にするために、同じタイプのデータを同じプールに保持します(vProxyセーブセット、ファイル システム セーブセット、Oracleデータベース セーブセットなど)は別々のプールに配置する必要があります。
- メディア データベース エラーに関連するメッセージを無視しないでください。懸念がある場合は、サポートにお問い合わせください。
NetWorkerのメディア データベースとストレージの関係に注意し、 Scan-Neededフラグを使用してボリュームを保護します。
- NetWorkerは、サーバ バックアップ ワークフローの一環として、有効期限プロセスを毎日実行します。このジョブは保存期間と依存関係を計算し、保存期間を過ぎていて期限が切れていない依存物がないセーブセットを期限切れにします。これが完了すると、NetWorkerは期限切れのディスクボリューム セーブセットをすべて削除しようとします。その後、各ボリュームに対してスペース再利用操作が実行され、対応するメディア データベース エントリーがないディスク メディアからセーブセット ファイルが削除されます。つまり、メディア データベースが破損した場合、またはデータベースを以前のポイント イン タイムにリカバリーした場合、有効なデータが削除される可能性があります。
- ディスク ボリュームに問題があると思われる場合は、有効なデータが削除されないように、ボリュームがアンマウントされ、スキャンが必要とマークされていることを確認します。これは、以前のポイント イン タイムにリカバリした後のボリュームにも適用されます(リカバリー ポイントの後に作成されたディスクに有効なセーブ セットが存在し、リカバリーされたデータベースにエントリーがない場合があります)。
- [Scan Needed]では、通常のバックアップ、リカバリー、クローニングを実行できますが、通常の有効期限や削除はできません。そのため、危険な状態にあると認識されたボリュームを保護するためにのみ使用し、通常の操作に戻ったときに削除します。このフラグを設定または削除するには、ボリュームをアンマウントする必要があります。NetWorkerサーバーのディザスター リカバリー後にボリュームに「スキャンが必要」とマークされることがよくあります(
nsrdr)を使用して、ディザスター リカバリー シナリオでの不要なデータ ロスを防ぎます。
解決方法
メディア データベースの問題を確認して修正するには、いくつかの方法があります。これらのいずれかを試す前に、影響を評価するために前後のレポートを作成して、セーブセット、ボリューム、クライアント、その他が削除されたかどうかを確認します
コマンド ラインで、出力をホストするディレクトリーで、次のコマンドを実行して、手順の前後にメディア データベースのプロパティを比較します。
mminfo -C mminfo-C_pre.mmimminfo -X mminfo-X_pre.mmimminfo -ar "volid,type,location,pool,volume,state,volflags,written,savesets" -q family=disk -xc, > mminfo-vol_pre.mmi
メンテナンスが完了したら、それぞれを別のファイル(例: *_post.mmi)をクリックし、値を比較します。
nsrim - 毎日のサーバー保護
Server Protection > Server Backup ワークフローが毎日実行され、それとともに Expiration アクションが実行されます。Expirationアクションが実行されます nsrimこれはNetWorkerのネイティブ メンテナンス ユーティリティーです。これは直接実行することもできますが、サーバーの負荷とメディア データベースのサイズに応じて、数分から数時間かかる場合があります。
nsrim -X > nsrim.out 2>&1
このプロセスを毎日実行できない限り、何かが変わる可能性は低くありません。デーモン ログで、次のことを確認します。 nsrim 毎日の完了。詳細については、次を参照してください。NetWorker:NetWorkerオンライン ファイルおよびメディア インデックスのメンテナンス操作をスケジュールする方法
サービスの再開
NetWorkerサービスを再起動すると、さまざまな起動チェックが強制的に実行され、デーモン ログのエラー メッセージに問題が表示される可能性がありますが、修正される可能性があります。サービスを停止する前に、データベースの問題が深刻であると思われる場合は、十分な空き領域があり、ブートストラップの場所がわかっていることを確認してください (mminfo -B output)です。理想的には、 nsrmmdbasm -s /nsr/mm/mmvolrel_path > mm.xdr 最初に、現在のメディア データベース コピーの抽出を試みます。サービスを再起動する前に、 /nsr/mm/mmvolrel 後でフォレンジックまたはリカバリーの目的で必要になる可能性があるフォルダー。詳細については、次を参照してください。nsrmmdbasmを使用してNetWorkerメディア データベースをエクスポートする方法
メディア データベースのエクスポートと再インポート。
このプロセスでは、実行可能なメディア データベース レコードのみを抽出し、サービスを停止せずにサーバーに再インポートすることで、完全なディザスター リカバリーを回避します。ただし、これはサーバーがアイドル状態のときにのみ行う必要があり、ジョブの実行中には絶対に試行しないでください。mmvolrelの代わりにフル パスを使用します(インストールまたはオペレーティング システムによって異なる場合があります)。
- 作業を開始する前に、アンマウント後にすべてのディスク ボリュームをスキャンが必要としてマークします。ディスク ボリュームをホストするデバイスに対して 自動メディア管理 が設定されている場合は、最初にこれを無効にする必要があります。テープ ボリュームでは、この手順は必要ありません。
メモ: 次の記事では、ボリュームを「スキャン不要」としてマークする方法について説明します。ただし、ボリュームを「Scan Needed」とマークするためにも使用できます。これを行うには、次の手順に従ってください。ただし、「不要」ではなく「スキャンが必要」に設定します 。ボリュームを「Scan is needed」から「scan is NOT needed」に変更する方法(英語)」を参照して手順を実施できます。
- 次のコマンド:
mminfoプリアンブルで説明されているコマンドを使用して、予備レポートを作成します。 - メディア データベースのサイズを確認します
mmvolrelフォルダーとレコード - 次のいずれにも該当しないことを確認します。
nsrck、nsrim、nsrmmdbasmプロセスは実行中です。MMの親フォルダーに大きなファイル、古いファイル、または最近変更されていないファイルがある場合mm/[alphanumerics]、移動、または削除 (どのプロセスによってもロックされていない場合)。 - メディア データベースをXDRファイルに抽出します。nsrmmdbasmを使用してNetWorkerメディア データベースをエクスポートする方法
- 新しいファイルのサイズと
mmvolrelfolder - サイズが類似している場合。小さい場合(4 Bまたは数KB)、コマンドは失敗しました。これより小さい場合は、プロセスの一環として破損したレコードが削除された可能性があります。 - NMC/NWUIでサーバー の状態 フィールドを ディザスター リカバリ ーに設定して、サーバーがメディア データベースをリカバリーできるように準備します。
nsradminの詳細を確認してください。 - を使用したメディア データベース抽出ファイルからの直接リカバリー
nsrmmdbasmコマンドを再度実行します。nsrmmdbasm -r -2 < mm.xdr - 完了したら、同じものを実行します
mminfoプリアンブルで説明されているように、 セーブセット と 書き込まれた 値を比較し、ボリュームごとに、すべてのボリュームが存在することを確認します。同様mminfo -C値は同一である必要があります。 - 不一致がある場合は、メモを取り、続行する方法を慎重に検討してください。表示される結果に確信が持てない場合は、サポートにお問い合わせください。
- 正常と表示されるボリュームについては、Scan-Neededフラグを削除してボリュームをマウントできます。 これは、セーブ セットと 書き込まれた 値に整合性があれば、ボリュームから削除されたように見えてもセーブセットが削除される危険がないためです。
- セーブセットの数が少ない、または書き込み合計が少ないボリュームでは、「Scan-Needed」フラグをそのままにして、スキャナーを実行します。
scanner -i devicenameレコードがなくなったボリューム上のファイルを再導入します。次に、scannerが各ボリュームに対して完了しました。セーブセット数をもう一度確認して、[ スキャンが必要]フラグを削除します。詳細については、NetWorker:ボリュームを「Scan is needed」から「scan is NOT needed」に変更する方法(英語)」を参照して手順を実施できます。 - 確信が得られたらボリュームを再マウントします
scanner欠落していると予想されるセーブセットを置き換えました。
NetWorkerサーバーのディザスター リカバリー(nsrdr)を作成します。
完全なディザスター リカバリーを実行する nsrdr メディア データベースだけでなく、リソース データベースやジョブ データベースなどの他のサーバー要素もリカバリーします。次の手順に進む前に、お使いのバージョンの 『サーバー ディザスター リカバリーおよび可用性のベスト プラクティス ガイド 』を参照してください
このコマンドは、完了するためには、ストレージ ノードがオンラインで接続可能であることを想定しています。次の資料も参照してください。NetWorker:NetWorkerサーバー ディザスター リカバリー(NSRDR)