日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

紛失した可能性のあるオブジェクトを検索して復元する

10/01/2025

PDF

*オブジェクト紛失*アラートと従来の紛失オブジェクト (LOST) アラームをトリガーし、紛失の可能性があると特定されたオブジェクトを見つけて復元できる可能性があります。

開始する前に

紛失したオブジェクトのUUIDは、"紛失物の調査" 。
あなたは `Passwords.txt`ファイル。

タスク概要

この手順に従って、グリッド内の他の場所で失われたオブジェクトの複製されたコピーを探すことができます。ほとんどの場合、紛失した物は見つかりません。ただし、場合によっては、迅速な対応を行えば、失われた複製オブジェクトを見つけて復元できる可能性があります。

この手順に関するサポートについては、テクニカルサポートにお問い合わせください。

手順

管理ノードから、監査ログでオブジェクトの可能性のある場所を検索します。

グリッドノードにログインします。
1. 次のコマンドを入力します。 ssh admin@grid_node_IP
2. 記載されているパスワードを入力してください `Passwords.txt`ファイル。
3. ルートに切り替えるには、次のコマンドを入力します。 su -
4. 記載されているパスワードを入力してください Passwords.txt`ファイル。ルートとしてログインすると、プロンプトは `$`に `#。

監査ログが保存されているディレクトリに変更します。

監査ログディレクトリと適用可能なノードは、監査の宛先設定によって異なります。

オプションデスティネーション

オプション	デスティネーション
ローカルノード（デフォルト）	`/var/local/log/localaudit.log`
管理ノード/ローカルノード	管理ノード (プライマリおよび非プライマリ): `/var/local/audit/export/audit.log` すべてのノード: `/var/local/log/localaudit.log`このモードでは通常、ファイルは空であるか、存在しません。
外部 syslog サーバー	`/var/local/log/localaudit.log`

ローカルノード（デフォルト）

/var/local/log/localaudit.log

管理ノード/ローカルノード

管理ノード (プライマリおよび非プライマリ): /var/local/audit/export/audit.log
すべてのノード: `/var/local/log/localaudit.log`このモードでは通常、ファイルは空であるか、存在しません。

外部 syslog サーバー

/var/local/log/localaudit.log

監査先の設定に応じて、次のように入力します。 cd /var/local/log`または `/var/local/audit/export/

詳細については、"監査情報の送信先を選択する" 。

grepを使用して抽出します"失われた可能性のあるオブジェクトに関連付けられた監査メッセージ"出力ファイルに送信します。入力： grep uuid-value audit_file_name > output_file_name

例えば：
```
Admin: # grep 926026C4-00A4-449B-AC72-BCCA72DD1311 audit.log > /var/local/tmp/messages_about_lost_object.txt
```

grep を使用して、この出力ファイルから Location Lost (LLST) 監査メッセージを抽出します。入力： grep LLST output_file_name

例えば：

Admin: # grep LLST /var/local/tmp/messages_about_lost_objects.txt

LLST 監査メッセージは、このサンプルメッセージのようになります。

[AUDT:[NOID(UI32):12448208][CBIL(UI64):0x38186FE53E3C49A5]
[UUID(CSTR):"926026C4-00A4-449B-AC72-BCCA72DD1311"][LTYP(FC32):CLDI]
[PCLD(CSTR):"/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA#3tN6"]
[TSRC(FC32):SYST][RSLT(FC32):NONE][AVER(UI32):10][ATIM(UI64):1581535134379225]
[ATYP(FC32):LLST][ANID(UI32):12448208][AMID(FC32):CLSM][ATID(UI64):7086871083190743409]]

LLST メッセージ内の PCLD フィールドと NOID フィールドを見つけます。

存在する場合、PCLD の値は、不足している複製されたオブジェクトのコピーへのディスク上の完全なパスです。 NOID の値は、オブジェクトのコピーが存在する可能性がある LDR のノード ID です。

オブジェクトの場所が見つかった場合は、オブジェクトを復元できる可能性があります。

この LDR ノード ID に関連付けられているストレージノードを検索します。グリッドマネージャーで、サポート > ツール > グリッドトポロジ を選択します。次に、データセンター > ストレージノード > LDR を選択します。

LDR サービスのノード ID は、ノード情報テーブルにあります。この LDR をホストしているストレージノードが見つかるまで、各ストレージノードの情報を確認します。

監査メッセージに示されているストレージノードにオブジェクトが存在するかどうかを確認します。
1. グリッドノードにログインします。
  1. 次のコマンドを入力します。 ssh admin@grid_node_IP
  2. 記載されているパスワードを入力してください `Passwords.txt`ファイル。
  3. ルートに切り替えるには、次のコマンドを入力します。 su -
  4. 記載されているパスワードを入力してください `Passwords.txt`ファイル。
    
    ルートとしてログインすると、プロンプトは $`に `#。
2. オブジェクトのファイルパスが存在するかどうかを判断します。
  
  オブジェクトのファイルパスには、LLST 監査メッセージの PCLD の値を使用します。
  
  たとえば、次のように入力します。
  ls '/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%#3tN6'
  特殊文字をエスケープするには、コマンド内のオブジェクトファイルパスを常に一重引用符で囲みます。
  - オブジェクトパスが見つからない場合、オブジェクトは失われ、この手順を使用して復元することはできません。テクニカルサポートにお問い合わせください。
  - オブジェクトパスが見つかった場合は、次の手順に進みます。見つかったオブジェクトをStorageGRIDに復元することができます。

オブジェクトパスが見つかった場合は、オブジェクトをStorageGRIDに復元します。

同じストレージノードから、オブジェクトファイルの所有権を変更して、 StorageGRIDで管理できるようにします。入力： chown ldr-user:bycast 'file_path_of_object'
LDR コンソールにアクセスするには、localhost 1402 に Telnet します。入力： telnet 0 1402
入力： cd /proc/STOR

入力： Object_Found 'file_path_of_object'

たとえば、次のように入力します。

Object_Found '/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%#3tN6'

発行 `Object_Found`コマンドは、オブジェクトの位置をグリッドに通知します。また、アクティブな ILM ポリシーをトリガーし、各ポリシーで指定されたとおりに追加のコピーを作成します。

オブジェクトが見つかったストレージノードがオフラインの場合、オンラインの任意のストレージノードにオブジェクトをコピーできます。オブジェクトをオンラインストレージノードの任意の /var/local/rangedb ディレクトリに配置します。次に、 `Object_Found`オブジェクトへのファイルパスを使用してコマンドを実行します。

オブジェクトを復元できない場合は、 `Object_Found`コマンドは失敗します。テクニカルサポートにお問い合わせください。

オブジェクトがStorageGRIDに正常に復元された場合は、成功メッセージが表示されます。例えば：

ade 12448208: /proc/STOR > Object_Found '/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%#3tN6'

ade 12448208: /proc/STOR > Object found succeeded.
First packet of file was valid. Extracted key: 38186FE53E3C49A5
Renamed '/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%#3tN6' to '/var/local/rangedb/1/p/17/11/00rH0%DkRt78Ila#3udu'

次の手順に進みます。

オブジェクトがStorageGRIDに正常に復元された場合は、新しい場所が作成されたことを確認します。
1. グリッドマネージャーにSign inには、"サポートされているウェブブラウザ" 。
2. ILM > オブジェクトメタデータ検索 を選択します。
3. UUIDを入力し、「検索」を選択します。
4. メタデータを確認し、新しい場所を確認します。
管理ノードから、このオブジェクトの ORLM 監査メッセージの監査ログを検索し、情報ライフサイクル管理 (ILM) によって必要に応じてコピーが配置されていることを確認します。
1. グリッドノードにログインします。
  1. 次のコマンドを入力します。 ssh admin@grid_node_IP
  2. 記載されているパスワードを入力してください `Passwords.txt`ファイル。
  3. ルートに切り替えるには、次のコマンドを入力します。 su -
  4. 記載されているパスワードを入力してください Passwords.txt`ファイル。ルートとしてログインすると、プロンプトは `$`に `#。
2. 監査ログが保存されているディレクトリに変更します。参照サブステップ1.b。
3. grep を使用して、オブジェクトに関連付けられた監査メッセージを出力ファイルに抽出します。入力： grep uuid-value audit_file_name > output_file_name
  
  例えば：
  Admin: # grep 926026C4-00A4-449B-AC72-BCCA72DD1311 audit.log > /var/local/tmp/messages_about_restored_object.txt
4. grep を使用して、この出力ファイルから Object Rules Met (ORLM) 監査メッセージを抽出します。入力： grep ORLM output_file_name
  
  例えば：
  Admin: # grep ORLM /var/local/tmp/messages_about_restored_object.txt
  ORLM 監査メッセージは、このサンプルメッセージのようになります。
```
[AUDT:[CBID(UI64):0x38186FE53E3C49A5][RULE(CSTR):"Make 2 Copies"]
[STAT(FC32):DONE][CSIZ(UI64):0][UUID(CSTR):"926026C4-00A4-449B-AC72-BCCA72DD1311"]
[LOCS(CSTR):"**CLDI 12828634 2148730112**, CLDI 12745543 2147552014"]
[RSLT(FC32):SUCS][AVER(UI32):10][ATYP(FC32):ORLM][ATIM(UI64):1563398230669]
[ATID(UI64):15494889725796157557][ANID(UI32):13100453][AMID(FC32):BCMS]]
```
1. 監査メッセージ内の LOCS フィールドを見つけます。
  
  存在する場合、LOCS 内の CLDI の値は、オブジェクトコピーが作成されたノード ID とボリューム ID です。このメッセージは、ILM が適用され、グリッド内の 2 つの場所に 2 つのオブジェクトコピーが作成されたことを示します。
"紛失した物や行方不明の物の数をリセットする"グリッドマネージャーで。

紛失した可能性のあるオブジェクトを検索して復元する

Creating your file...