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

失われた可能性があるオブジェクトを検索してリストアします

11/07/2024 共同作成者

PDF

「* Object Lost *」アラートと従来のLost Objects（LOST）アラームをトリガーした、失われた可能性があると特定したオブジェクトを検索してリストアできる場合があります。

開始する前に

で特定した損失オブジェクトのUUIDを確認しておき"損失オブジェクトを調査する"ます。
あなたはファイルを持ってい `Passwords.txt`ます。

タスクの内容

この手順を使用して、グリッド内の他の場所で損失オブジェクトのレプリケートコピーを検索できます。ほとんどの場合、損失オブジェクトは見つかりません。ただし、迅速に対処すれば、損失レプリケートオブジェクトを検索してリストアできる場合があります。

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

手順

管理ノードの監査ログで、オブジェクトが存在する可能性のある場所を検索します。
1. グリッドノードにログインします。
  1. 次のコマンドを入力します。 ssh admin@grid_node_IP
  2. ファイルに記載されているパスワードを入力し `Passwords.txt`ます。
  3. 次のコマンドを入力してrootに切り替えます。 su -
  4. ファイルに記載されているパスワードを入力し Passwords.txt`ます。rootとしてログインすると、プロンプトがからに `#`変わります `$。
2. 監査ログが保存されているディレクトリに移動します。 cd /var/local/log/
  
  "監査情報の保存先について"です。
3. grepを使用してを抽出し"損失の可能性があるオブジェクトに関連付けられている監査メッセージ"、出力ファイルに送信します。入力： grep uuid-value audit_file_name > output_file_name
  
  例：
  Admin: # grep 926026C4-00A4-449B-AC72-BCCA72DD1311 audit.log > messages_about_lost_object.txt
4. grep を使用して、この出力ファイルから Location Lost （ LLST ）監査メッセージを抽出します。入力： grep LLST output_file_name
  
  例：
  Admin: # grep LLST 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]]
5. LLST メッセージで PCLD フィールドと NOID フィールドを検索します。
  
  PCLD の値は、欠落しているレプリケートオブジェクトコピーへのディスク上の完全なパスです。NOID の値は、オブジェクトのコピーが存在する可能性のある LDR のノード ID です。
オブジェクトの場所が見つかった場合は、オブジェクトをリストアできる場合があります。
1. このLDRノードIDに関連付けられているストレージノードを探します。Grid Manager で、 * support * > * Tools * > * Grid topology * を選択します。次に、「 * _ データセンター _ * > * _ ストレージノード _ * > * LDR * 」を選択します。
  
  LDRサービスのノードIDは、[Node Information]テーブルに表示されます。この LDR をホストしているストレージノードが見つかるまで、各ストレージノードの情報を確認します。
監査メッセージで指定されているストレージノードにオブジェクトが存在するかどうかを確認します。
1. グリッドノードにログインします。
  1. 次のコマンドを入力します。 ssh admin@grid_node_IP
  2. ファイルに記載されているパスワードを入力し `Passwords.txt`ます。
  3. 次のコマンドを入力してrootに切り替えます。 su -
  4. ファイルに記載されているパスワードを入力し `Passwords.txt`ます。
    
    rootとしてログインすると、プロンプトがからに #`変わります `$。
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'
Telnet で localhost 1402 に接続して、 LDR コンソールにアクセスします。入力： 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. を使用してGrid Managerにサインインし"サポートされている Web ブラウザ"ます。
2. ILM * > * Object metadata lookup * を選択します。
3. UUIDを入力し、*[検索]*を選択します。
4. メタデータを確認し、新しい場所を確認します。
管理ノードから、監査ログを検索してこのオブジェクトを ORLM 監査メッセージで探し、必要に応じて情報ライフサイクル管理（ ILM ）によってコピーが配置されていることを確認します。
1. グリッドノードにログインします。
  1. 次のコマンドを入力します。 ssh admin@grid_node_IP
  2. ファイルに記載されているパスワードを入力し `Passwords.txt`ます。
  3. 次のコマンドを入力してrootに切り替えます。 su -
  4. ファイルに記載されているパスワードを入力し Passwords.txt`ます。rootとしてログインすると、プロンプトがからに `#`変わります `$。
2. 監査ログが保存されているディレクトリに移動します。 cd /var/local/log/
3. grep を使用して、オブジェクトに関連付けられている監査メッセージを出力ファイルに抽出します。入力： grep uuid-value audit_file_name > output_file_name
  
  例：
  Admin: # grep 926026C4-00A4-449B-AC72-BCCA72DD1311 audit.log > messages_about_restored_object.txt
4. grep を使用して、この出力ファイルから Object Rules Met （ ORLM ）監査メッセージを抽出します。入力： grep ORLM output_file_name
  
  例：
  Admin: # grep ORLM 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 フィールドを検索します。
  
  このフィールドの CLDI の値は、オブジェクトコピーが作成されたノード ID とボリューム ID です。このメッセージは、 ILM が適用され、 2 つのオブジェクトコピーがグリッド内の 2 つの場所に作成されたことを示しています。
"損失オブジェクトと欠落オブジェクトのカウントをリセットします"をクリックします。

失われた可能性があるオブジェクトを検索してリストアします

Creating your file...