> ## Documentation Index
> Fetch the complete documentation index at: https://docs.injective.network/llms.txt
> Use this file to discover all available pages before exploring further.

# バリデーターのトラブルシューティング

Injectiveのバリデーターおよびノードオペレーター向けのトラブルシューティングリファレンスと運用ガイドです。よくある障害パターン、復旧手順、アップグレードチェックリスト、および重要な安全対策を説明します。

***

## はじめに：重要な安全ルール

<Callout icon="warning" color="#FF8C00" iconType="regular">
  **絶対にしてはいけないこと**

  1. **同じ `priv_validator_key.json` を持つ2つのノードを同時に実行しないでください。** 二重署名が発生し、スラッシュは0%ですが、恒久的なトゥームストーン（tombstone）につながります。そのバリデーターは二度とアクティブセットに復帰できません。
  2. **結果を完全に理解していない限り、バリデーターノードで `unsafe-reset-all` を使用しないでください。** コンセンサスstateが消去され、トゥームストーンにつながる矛盾した投票を生成する可能性があります。
  3. **ノードが稼働中の状態で `priv_validator_state.json` をバックアップしないでください。** このファイルはコンセンサス中に絶えず変化します。まずノードを完全に停止してからコピーしてください。
  4. **バックアップした `priv_validator_state.json` を復元せずに、スナップショット復旧後のノードを起動しないでください。** スナップショットにはこのファイルが含まれません。復元せずに起動すると署名stateがブロック高0にリセットされ、二重署名を引き起こします。
  5. **アーカイブノードや大きな履歴を持つノードは、事前にテストせずにロールバックしないでください。** 大規模なデータベースでのロールバックは数時間かかるか、ノードを完全に使用不能にする可能性があります。特にPebbleDBでは注意が必要です。

  **必ずすべきこと**

  1. **ロールバック、スナップショット復元、バイナリアップグレードなどの復旧作業の前には、必ずノードを完全に停止してから `priv_validator_state.json` をバックアップしてください。**
  2. **ロールバックやスナップショット復旧の後、ノードを起動する前に、必ず `priv_validator_state.json` を元の場所に復元してください。**
  3. **ノードを起動する前に、必ず `priv_validator_state.json` が破損していないことを確認してください。** height、round、stepの値が妥当かどうかをチェックしてください。
  4. **協調アップグレードでは必ず `--halt-height` を設定してください。** halt-heightフラグを設定しなかったノードは、より困難な復旧手順が必要になります。
  5. **アップグレード後の起動前に、必ず `injectived version` でバイナリのバージョンを確認してください。**
  6. **チェーンが安定したら、一時的なコンセンサスの上書き設定（`--unsafe-consensus-timeout-precommit-delta=1ms` など）を必ず元に戻してください。**
</Callout>

<Callout icon="info" color="#22C55E" iconType="regular">
  **復旧用のスナップショットが必要ですか？** プルーニングされたスナップショットとコミュニティプロバイダーについては、このページの下部にある[スナップショットリソース](#スナップショットリソース)を参照してください。アーカイブセグメントのスナップショットについては、[アーカイブセットアップ](/jp/infra/archival-setup)ページを参照してください。
</Callout>

***

## よくある問題と解決策

### アップグレード高でノードが停止したまま進まない

**症状：**

* ノードログに、想定されたアップグレード高でチェーンが停止したことが表示される
* `latest_block_height` が停止高を超えて進まない

**原因：** ノードが古いバイナリを実行しています。チェーンはアップグレード高を超えて進むために、アップグレード済みのバイナリを必要とします。

**解決策：**

1. ノードを停止する
2. `~/.injectived/data/priv_validator_state.json` をバックアップする
3. 新しいバイナリをインストールする
4. 確認する：`injectived version`
5. ノードを起動する

***

### アップグレード後のブロックヘッダーハッシュの不一致

**症状：**

```
ERR prevote step: consensus deems this block invalid; prevoting nil
err="wrong Block.Header.LastResultsHash. Expected 284C339C..., got 694706724..."
```

ノードが継続的にnilにprevoteし、次のブロックをファイナライズできません。

**原因：** アップグレード高におけるノードのローカルstateが、新しいバイナリが期待するstateと一致していません。これは、アップグレード前に古いバイナリのロジックでhalt-heightのブロックを処理してしまった場合に発生します。

**解決策：**

1. ノードを停止する
2. `priv_validator_state.json` をバックアップする
3. 1ブロックロールバックする：
   ```bash theme={null}
   injectived rollback
   ```
4. `priv_validator_state.json` を復元する
5. 新しいバイナリでノードを起動する

<Warning>
  大規模なデータベース（数百GB）を持つアーカイブノードでのロールバックは、非常に長い時間がかかるか失敗する可能性があります。これらのノードでは、代わりにスナップショットから復旧してください。
</Warning>

***

### 矛盾した投票（conflicting vote）の警告

**症状：**

```
ERR Found conflicting vote from ourselves; did you unsafe_reset a validator?
height=181027006 module=consensus round=40 type=SIGNED_MSG_TYPE_PREVOTE
```

このメッセージが継続的に繰り返されます。

**原因：** ノードの `priv_validator_state.json` がリセットまたは破損したため、すでに署名済みのラウンドに再度署名し、矛盾した投票を生成しています。

**よくある引き金：**

* バリデーターで `unsafe-reset-all` を実行した
* 古い、または誤った `priv_validator_state.json` を復元した
* ノードが稼働中の状態で `priv_validator_state.json` をバックアップした（古いコピー）
* rollbackコマンドがバリデーターstateをリセットした

**解決策：**

* （ノードを完全に停止した後に取得した）正しい `priv_validator_state.json` のバックアップがある場合：それを復元して再起動してください。
* 正しいバックアップがない場合：**直ちにノードを停止し、ブロック生成が再開されるのを待ってから再起動してください。** 誤ったstateで起動すると二重署名のリスクがあります。
* 署名情報を確認する：
  ```bash theme={null}
  injectived query slashing signing-info <injvalcons_address>
  ```

<Warning>
  矛盾した投票がオンチェーンで検出されると、バリデーターはトゥームストーン（恒久的なジェイル）になります。二重署名に対するオンチェーンでのunjailは存在しません。
</Warning>

***

### バリデーターがトゥームストーンされた（二重署名）

**症状：**

```
injectived query slashing signing-info injvalcons1...
  tombstoned: true
  jailed_until: "9999-12-31T23:59:59Z"
```

**原因：** バリデーターが同じブロック高で2つの異なるブロックまたはprevoteに署名しました。よくある引き金：

* 同じ署名キーでノードの2つのインスタンスを実行した
* 古い `priv_validator_state.json` を復元したことで、すでに署名済みのブロック高で再署名が発生した
* ロールバックによって署名stateがリセットされ、その後ノードが矛盾したブロックに署名した

**対応方法：**

トゥームストーンされたバリデーターに対する標準的なオンチェーンのunjailは存在しません。対応の選択肢：

* 影響を受けたバリデーターのトゥームストーンを明示的に解除するガバナンスプロポーザルまたはアップグレードハンドラー
* 新しいオペレーターキーで新しいバリデーターを作成する（既存のデリゲーションは失われます）

<Warning>
  **協調セキュリティアップグレード中にトゥームストーンされた場合は**、直ちに認証済みバリデーターチャンネルでInjectiveチームに連絡してください。協調アップグレードの際、チームは影響を受けたバリデーターを復旧するためのトゥームストーン解除ハンドラーをアップグレードバイナリに含めることがあります。時間に敏感な対応であるため、アップグレードハンドラーが確定する前に含めてもらえるよう、できるだけ早く報告してください。
</Warning>

**予防策：**

* ハードウェアで強制されるシングルサイナーのセマンティクスのために、TMKMSまたはHorcruxを使用する
* ノードを停止した後に必ず `priv_validator_state.json` をバックアップする
* 同じ署名キーで2つのノードを同時に実行しない

***

### スナップショットからの復旧

**使用すべきタイミング：** ロールバックが失敗する、時間がかかりすぎる、またはノードのstateが修復不可能なほど破損している場合（AppHashの不一致）。

**手順：**

1. ノードを完全に停止する
2. `~/.injectived/data/priv_validator_state.json` をバックアップする
3. 他の場所にバックアップしていない場合は `~/.injectived/config/priv_validator_key.json` もバックアップする
4. 信頼できるプロバイダーからスナップショットをダウンロードする：
   * Injectiveチームがセキュリティアップグレードの前や最中に緊急スナップショットを共有する場合もあります
   * [Polkachu Injective Snapshots](https://polkachu.com/tendermint_snapshots/injective)（通常goleveldb）
   * コミュニティのバリデーターがインシデント時に緊急スナップショットを共有することがあります
5. 古いデータを削除する：
   ```bash theme={null}
   rm -rf ~/.injectived/data
   ```
6. スナップショットを `~/.injectived/data/` に展開する
7. **バックアップしておいた `priv_validator_state.json` を `~/.injectived/data/` に復元する**
8. `priv_validator_state.json` が存在し、内容が正しいことを確認する
9. ノードを起動する

#### 自分の `priv_validator_state.json` を必ず保持しなければならない理由

スナップショットにはブロックチェーンデータ（ブロック、アプリケーションstate）が含まれますが、バリデーターの署名stateは決して含まれません。署名stateは、バリデーターが最後に署名したheight、round、stepを記録しています。これを失ったり空のファイルで置き換えたりすると、ノードは自分がすでに何に署名したかを認識できず、矛盾したブロックに署名する可能性があります。その結果、二重署名と恒久的なトゥームストーンが発生します。

署名stateが常にスナップショットのブロック高以上でなければならない理由を示す、実践的な例を挙げます。

**前提：** ブロック125をhalt-heightとする協調チェーンアップグレード。

```
Block:  100  105  110  115  120  125  126
         |    |    |    |    |    |    |
         |    |    |    |    |    |    Chain resumes with new binary
         |    |    |    |    |    Chain halts here (upgrade height)
         |    |    |    |    |
         |    |    |    Snapshot taken at block 115
         |    |    |
         Your node has been signing every block...
```

停止時点で、あなたの `priv_validator_state.json` は次のようになっています：

```json theme={null}
{
  "height": "126",
  "round": 42,
  "step": 3,
  "signature": "...",
  "signbytes": "..."
}
```

**停止高が125なのに、なぜheightが126になっているのでしょうか？** `--halt-height` フラグはブロック126が*コミット*（ファイナライズ）されるのを防ぎますが、CometBFTコンセンサスエンジンはそれでもブロック高126に入り、アプリケーション層がブロックの処理を拒否してノードがシャットダウンするまで、そのラウンド（プロポーズ、prevote、precommit）を開始します。高いラウンド番号（42）は、バリデーターが徐々に停止していく中でコンセンサスに到達できず、ネットワークがラウンドを重ねたことを反映しています。これは正常な動作です：ブロック126は一度もファイナライズされなかったにもかかわらず、あなたのバリデーターはブロック高126で実際に投票を行ったのです。

つまり、あなたのバリデーターはすでにブロック高126、ラウンド42で投票を行っています。利用可能なスナップショットはブロック高115のものです。

**署名stateなしでスナップショットを復元するとどうなるか：**

スナップショットには `priv_validator_state.json` が含まれないか、空のもの（height 0）が付属します。この状態でノードを起動すると：

1. ノードはブロック高115からブロックチェーンデータをロードする
2. ブロック116〜125をリプレイしてブロック高126まで追いつく
3. ブロック高126でコンセンサスに入り、ラウンド0から署名を開始する
4. しかし、ネットワークにはこのブロック高でのラウンド42のあなたの投票がすでに存在する
5. あなたのノードはブロック高126で別のブロック提案に署名する（新しいバイナリでリプレイしたため、異なる結果を生成する可能性がある）
6. ネットワークが、あなたのバリデーターキーからの2つの矛盾した署名を検出する
7. **あなたのバリデーターは二重署名となり、トゥームストーンされます。恒久的に。**

**正しい手順：**

1. ノードを停止する
2. `priv_validator_state.json` をバックアップする（height 126、round 42と記録されている）
3. データディレクトリを削除する
4. スナップショット（ブロック高115からのブロックチェーンデータ）を展開する
5. **バックアップした `priv_validator_state.json` をデータディレクトリに書き戻す**
6. ノードを起動する

このときノードが起動すると：

1. ブロック高115からブロックチェーンデータをロードする
2. ブロック116〜125をリプレイしてブロック高126まで追いつく
3. ブロック高126で署名stateを読み取る：「ラウンド42まではすでに署名済み」
4. ラウンド0〜42をスキップし、新たに署名する前にラウンド43を待つ
5. 矛盾した投票は発生しません。あなたのバリデーターは安全です。

<Warning>
  **重要なルール：** 署名stateは、バリデーターがこれまでに署名した最も高い地点を常に反映していなければなりません。署名stateがスナップショットより先にあるのは安全です（ノードが追いつきます）。署名stateが、バリデーターがネットワーク上で実際に署名した地点より後ろにあることは決して安全ではありません。
</Warning>

| シナリオ                 | 署名stateのブロック高 | スナップショットのブロック高 | 安全か？                                          |
| -------------------- | ------------- | -------------- | --------------------------------------------- |
| 通常の復旧                | 126           | 115            | はい -- ノードは116〜125をリプレイし、126では署名済みラウンドをスキップします |
| 新しいスナップショット、stateを保持 | 126           | 120            | はい -- 同じロジックで、リプレイするブロックが少なくなります              |
| stateなしのスナップショット     | 0             | 115            | **いいえ** -- すでに署名済みのブロック高で再署名し、二重署名を引き起こします    |
| 古いバックアップ（110で取得）     | 110           | 115            | **いいえ** -- ブロック高111〜126で再署名します                |

**データベースバックエンドの互換性：** スナップショットはバックエンド固有です。goleveldbのスナップショットはpebbledb向けに設定されたノードでは動作せず、その逆も同様です。設定を確認してください：

```bash theme={null}
grep db_backend ~/.injectived/config/config.toml
```

***

### ロールバックがハングまたは失敗する

**症状：** `injectived rollback` は実行されるが完了しない、またはエラーを出力する。

**原因：**

* **PebbleDBバックエンド：** pebbleでのロールバックには既知の問題があり、無期限にハングする可能性があります
* **非常に大きなデータベース：** ロールバック時間はデータベースのサイズに比例します
* **破損したWAL**（Write-Ahead Log）

**解決策：**

* PebbleDBノードの場合：代わりにスナップショットから復旧してください
* 大規模ノードの場合：ロールバックが30分以上経っても完了しない場合は中断し、スナップショットを使用してください
* goleveldbへの切り替えを検討してください。PebbleDBはスペース効率に優れていますが、ロールバックに関するテストは十分ではありません

***

### キャッチアップ中のラウンド後退エラー

**症状：**

```
ERR Failed signing vote err="error signing vote: round regression at height 181027006.
Got 108, last round 141"
```

**原因：** ノードが現在のコンセンサスラウンドに追いついている途中です。多くのラウンドを経て進行中のアクティブなコンセンサスラウンドの最中にノードを再起動した場合、これは正常かつ想定された動作です。

**解決策：** 対応は不要です。ノードは追いつきます。ラウンドのキャッチアップを高速化するには：

```bash theme={null}
# Flag
--unsafe-consensus-timeout-precommit-delta=1ms

# Or environment variable
INJECTIVED_UNSAFE_CONSENSUS_TIMEOUT_PRECOMMIT_DELTA=1ms
```

<Warning>
  **チェーンが安定し、ノードが追いついたら、この上書き設定を削除してください。** デフォルト（100ms）に戻して再起動してください。

  通常運用中にこの設定を残しておくと、1msのデルタによって、投票がネットワークを伝播できる速度よりはるかに速くラウンドが進んでしまいます。他のバリデーターのprecommitが届く前にあなたのバリデーターは次のラウンドへ移ってしまい、その投票は実際のコミットラウンドを外してしまいます。その結果、ブロックミスのカウンターが着実に増え続け、十分な数のブロックをミスすると（通常、直近10,000ブロック中500ブロック）、**バリデーターはダウンタイムによりジェイルされます**。
</Warning>

***

### AppHashの不一致

**症状：**

```
panic: Tendermint state.AppHash does not match AppHash after replay
```

**原因：** アプリケーションstateがコンセンサスstateから乖離しました。不完全なアップグレード、ブロック実行中のクラッシュ、またはデータベースの破損によって発生する可能性があります。

**解決策：**

1. ロールバックを試す：`injectived rollback`
2. ロールバックが失敗するかエラーが続く場合：スナップショットから復旧する
3. 復旧後は必ず `priv_validator_state.json` を復元する

***

### アップグレード後にセントリーノードが停止したまま

**症状：** バリデーターノードはアップグレード済みで署名しているが、セントリーノードは古いブロック高で停止したままになっている。

**原因：** セントリーノードも、アップグレード高を超えてブロックを処理するために新しいバイナリを必要とします。

**解決策：** セントリーノードをバリデーターと同じバージョンのバイナリにアップグレードしてください。セントリーは `priv_validator_state.json` を持ちません（署名を行わないため）が、正しいバイナリは必要です。

***

### アップグレード後にチェーンが停滞する（投票パワー不足）

**症状：**

* アップグレード高の後、チェーンが新しいブロックを生成しない
* コンセンサスのラウンド番号が継続的に増加する（ラウンド50、100、200以上）
* ノードはprevoteとprecommitをログに記録しているが、ブロックはコミットされない
* `latest_block_height` が停止高で止まったまま

**原因：** CometBFTがブロックをファイナライズするには、合計投票パワーの2/3超が正しいバイナリでオンラインになり、参加している必要があります。協調アップグレードの間、バリデーターがそれぞれ異なる速度でアップグレードを行う時間帯が発生します。十分な投票パワーが新しいバイナリを実行するまで、ネットワークはコンセンサスに到達できません。

この時間帯に起きること：

1. チェーンがアップグレード高で停止する（例：ブロック125）
2. アップグレード済みのバリデーターがブロック高126でコンセンサスへの参加を開始する
3. 各ラウンドでネットワークはブロック126のファイナライズを試みるが、投票パワーの2/3未満しか投票していないため失敗する
4. ラウンド番号が増加し、サイクルが繰り返される。ラウンド1、2、3、…50、…100以上
5. 十分な数のバリデーターがアップグレードを完了してオンラインになるまで、これが続く

**これはアップグレード中の正常な動作です。** チェーンが壊れているのではなく、クォーラム（定足数）を待っている状態です。

**取るべき対応：**

* **すでにアップグレード済みの場合：** 対応は不要です。あなたのノードは参加しており、クォーラムに達すると自動的に次のブロックをファイナライズします。ノードがラウンドを追いかける間、ログにラウンド後退エラーが表示されますが、これは想定内です（[キャッチアップ中のラウンド後退エラー](#キャッチアップ中のラウンド後退エラー)を参照）。
* **まだアップグレードしていない場合：** あなたは不足している投票パワーの一部です。チェーンの再開を助けるため、できるだけ早くアップグレードを完了してください。
* **進捗を監視する：** オンラインで参加しているバリデーターの数を確認する：
  ```bash theme={null}
  curl -s localhost:26657/consensus_state | jq '.result.round_state.votes'
  ```
* **バリデーターチャンネルで連携する：** 大規模なアップグレードの際、バリデーターは通常、認証済みバリデーターチャンネルで連携し、アップグレードの進捗と投票パワーの割合を追跡します。

<Note>
  この時間帯が長引くほど、ラウンド番号は高くなります。後からオンラインになるバリデーターは、それらすべてのラウンドを追いかける必要があります。`--unsafe-consensus-timeout-precommit-delta=1ms` フラグが存在するのはこのためですが、[チェーンが安定したら削除する](#キャッチアップ中のラウンド後退エラー)ことを忘れないでください。
</Note>

***

### ダウンタイムによるジェイル（トゥームストーンではない）

**症状：**

* バリデーターが非アクティブまたはジェイル状態と表示される
* 署名情報で `tombstoned: false` になっている
* ブロックミスのカウンターが高い

**原因：** バリデーターが連続して多くのブロックをミスしました（通常、直近10,000ブロック中500ブロック）。

**解決策：**

1. ノードが稼働しており、最新のブロックまで完全に追いついていることを確認する
2. unjailを実行する：
   ```bash theme={null}
   injectived tx slashing unjail \
     --from=<key_name> \
     --chain-id=injective-1 \
     --gas=auto \
     --gas-adjustment=1.5
   ```
3. バリデーターが再びアクティブになったことを確認する：
   ```bash theme={null}
   injectived query staking validator <injvaloper_address>
   ```

***

## 協調アップグレードチェックリスト

### アップグレード高の前

* [ ] ガバナンスプロポーザルまたはチェーンチームから、目標のhalt-heightを確認する
* [ ] 新しいバイナリをダウンロードして検証する（sha256チェックサムを確認）
* [ ] ノード設定またはCLIフラグで `--halt-height=<target_height>` を設定する
* [ ] Cosmovisorを使用している場合：正しいアップグレードディレクトリに新しいバイナリを配置する
* [ ] `priv_validator_state.json` をバックアップする
* [ ] ロールバックが必要になった場合に備えて、スナップショットプロバイダーを把握しておく
* [ ] チェーンが停止高に向かって進行するのを監視する

### アップグレード高の時点

* [ ] ノードが想定した高さで停止したことを確認する
* [ ] ノードを完全に停止する（プロセスが終了していることを確認する）
  ```bash theme={null}
  ps aux | grep injectived
  ```
* [ ] `priv_validator_state.json` をバックアップする
* [ ] 新しいバイナリをインストールする
* [ ] バージョンを確認する：
  ```bash theme={null}
  injectived version
  ```

### アップグレード後

* [ ] 新しいバイナリでノードを起動する
* [ ] コンセンサスへの参加状況をログで監視する
* [ ] prevoteが正しいことを確認する（すべてのラウンドでnilに投票していないこと）
* [ ] エクスプローラー（[Mintscan](https://www.mintscan.io/injective/validators)）で投票パワーを監視する
* [ ] `wrong Block.Header.LastResultsHash` が表示された場合：停止し、1ブロックロールバックし、`priv_validator_state.json` を復元して再起動する
* [ ] ラウンドキャッチアップの上書き設定（`--unsafe-consensus-timeout-precommit-delta`）を使用している場合：安定したら削除する
* [ ] バリデーターが署名していることを確認する：
  ```bash theme={null}
  curl -s localhost:26657/consensus_state | jq '.result.round_state["height/round/step"]'
  ```

***

## モニタリングリファレンス

### コンセンサスと同期のステータス

```bash theme={null}
# Current consensus state (height, round, step)
curl -s localhost:26657/consensus_state \
  | jq '.result.round_state["height/round/step"] | split("/") | {height: .[0], round: .[1], step: .[2]}'

# Latest block height
curl -s localhost:26657/status | jq '.result.sync_info.latest_block_height'

# Whether the node is still catching up
curl -s localhost:26657/status | jq '.result.sync_info.catching_up'
```

### バリデーターの健全性

```bash theme={null}
# Signing info (missed blocks, jail status, tombstone status)
injectived query slashing signing-info $(injectived tendermint show-validator)

# Validator status and jail state
injectived query staking validator <injvaloper_address> --output json | jq '.status, .jailed'
```

### ノード設定

```bash theme={null}
# Current binary version
injectived version

# Current priv_validator_state (check height/round/step)
cat ~/.injectived/data/priv_validator_state.json | jq

# Database backend
grep db_backend ~/.injectived/config/config.toml
```

***

## プルーニングされたノードとアーカイブノードの比較

|                | プルーニングされたノード                | アーカイブノード                    |
| -------------- | --------------------------- | --------------------------- |
| **ロールバック**     | 高速（数分）                      | 低速（数分〜数時間）、失敗する可能性あり        |
| **スナップショット復旧** | 高速（10〜30分）                  | 非常に低速（数時間、スナップショットは100 GB超） |
| **一般的なDBサイズ**  | 10〜50 GB                    | 500 GB超                     |
| **推奨される復旧方法**  | まずロールバック、フォールバックとしてスナップショット | スナップショットを推奨、ロールバックはリスクあり    |

***

## その他のリソース

* [Injectiveノードの実行](/jp/infra/run-node)
* [Cosmovisorセットアップ](/jp/infra/cosmovisor)
* [ノードのアップグレード](/jp/infra/upgrade-node)
* [Cosmos Validators FAQ](https://github.com/cosmos/cosmos/blob/master/VALIDATORS_FAQ.md)
* [CometBFT Running in Production](https://docs.tendermint.com/v0.34/tendermint-core/running-in-production.html)

***

## スナップショットリソース

### Injective提供のスナップショット

Injectiveは、2つのリージョンでプルーニングされたメインネットスナップショットを維持しています。最新の利用可能なブロック高とダウンロードURLについては、ステータスエンドポイントを確認してください：

| リージョン         | ステータス                                                                                         | ダウンロード                                                                |
| ------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
| **EU (OVH)**  | [status.json](http://injective-mainnet-snapshots.s3-website.gra.io.cloud.ovh.net/status.json) | `http://injective-mainnet-snapshots.s3-website.gra.io.cloud.ovh.net/` |
| **アジア (GCS)** | [status.json](https://storage.googleapis.com/injective-mainnet-snapshots-asia/status.json)    | `https://storage.googleapis.com/injective-mainnet-snapshots-asia/`    |

最新のスナップショットをダウンロードするには、ステータスエンドポイントで現在のファイル名を確認してください：

```bash theme={null}
# Check latest available snapshot (Asia example)
curl -s https://storage.googleapis.com/injective-mainnet-snapshots-asia/status.json | jq

# Download the snapshot
wget <url from status.json>

# Extract
lz4 -d <snapshot_file>.tar.lz4 | tar xf - -C ~/.injectived/data/
```

協調セキュリティアップグレードの際、Injectiveチームが認証済みバリデーターチャンネルで緊急スナップショットを共有することもあります。アーカイブセグメントのスナップショットについては、[アーカイブセットアップ](/jp/infra/archival-setup)ページを参照してください。

### コミュニティのスナップショットプロバイダー

* [Polkachu Injective Snapshots](https://polkachu.com/tendermint_snapshots/injective)（通常goleveldb、プルーニング済み）
* [HighStakes Injective Snapshots](https://tools.highstakes.ch/snapshots/injective)
* コミュニティのバリデーターがインシデント時にバリデーターチャンネルで緊急スナップショットを共有することがあります

<Warning>
  **データベースバックエンドの互換性：** スナップショットはバックエンド固有です。goleveldbのスナップショットはpebbledb向けに設定されたノードでは動作せず、その逆も同様です。ダウンロードする前に設定を確認してください：

  ```bash theme={null}
  grep db_backend ~/.injectived/config/config.toml
  ```

  スナップショット復旧の後、ノードを起動する前に、**バックアップしておいた `priv_validator_state.json` をデータディレクトリに必ず復元してください。** 完全な手順については、上記の[スナップショットからの復旧](#スナップショットからの復旧)を参照してください。
</Warning>