Elasticsearch の手動スナップショットを作成してデータをリストアする - Elasticsearch

Elasticsearch の手動スナップショットを使用して、インデックスデータを OSS にバックアップし、オンデマンドでリストアします。これらは、データ移行、ポイントインタイムリカバリ、開発/テスト環境のセットアップ、または操作前のバックアップに使用できます。

バックアップとリストアには、elasticsearch-repository-oss プラグインが必要です。このプラグインは、すべての Alibaba Cloud Elasticsearch インスタンスにプリインストールされており、アンインストールできません。

スナップショットはインデックスデータのみを保存し、モニタリングインデックス (.monitoring、.security_audit) 、メタデータ、トランザクションログ、設定、パッケージ、プラグイン、ログは含まれません。すべてのコマンドは Kibana の Dev Tools で実行してください。「Kibana コンソールへのログイン」をご参照ください。

スナップショットリポジトリの作成

スナップショットリポジトリは、OSS バケットにスナップショットを保存します。Elasticsearch インスタンスと同じリージョンに、標準クラスの OSS バケットを準備してください (バケットの作成)。RAM ユーザーには AliyunOSSFullAccess ポリシーが必要です (RAM ユーザーへの権限付与)。

例： my_backup という名前のリポジトリを作成します。

Alibaba Cloud クラスター

PUT /_snapshot/my_backup
{
    "type": "oss",
    "settings": {
        "endpoint": "http://oss-cn-hangzhou-internal.aliyuncs.com",
        "access_key_id": "xxxx",
        "secret_access_key": "xxxxxx",
        "bucket": "xxxxxx",
        "compress": true,
        "chunk_size": "500mb",
        "base_path": "snapshot/"
    }
}

セルフマネージド 8.x クラスター

セルフマネージドクラスターでは、elasticsearch-repository-oss プラグインの手動インストールが必要です。すべてのパラメーター名の前に oss.client. を付ける必要があります。

PUT /_snapshot/my_backup
{
    "type": "oss",
    "settings": {
        "oss.client.endpoint": "oss-cn-shanghai.aliyuncs.com",
        "oss.client.access_key_id": "xxx",
        "oss.client.secret_access_key": "xxx",
        "oss.client.bucket": "xxxxxx",
        "oss.client.base_path":"snapshot/",
        "oss.client.compress": true
    }
}

パラメーター

パラメーター	説明
endpoint	OSS バケットの内部エンドポイントです。「リージョンとエンドポイント」をご参照ください。
access_key_id	RAM ユーザーの AccessKey ID です。「AccessKey ペアの取得」をご参照ください。
secret_access_key	RAM ユーザーの AccessKey シークレットです。「AccessKey ペアの取得」をご参照ください。
bucket	既存の OSS バケットの名前です。
compress	スナップショットのメタデータ (インデックスマッピングと設定) を圧縮します。データファイルには影響しません。デフォルト： `false`。
chunk_size	OSS へのアップロード時の最大チャンクサイズです。この制限を超えるファイルは、複数のチャンクに分割されます。
base_path	バケット内のストレージパスです。デフォルトはルートです。 `snapshot/prod/` や `snapshot/dev/` のように、サブディレクトリを使用してクラスターや環境ごとにスナップショットを分離します。

リポジトリ接続の検証

POST _snapshot/my_backup/_verify

レスポンスが成功すると、リポジトリに接続されているすべてのノードが一覧表示されます。失敗した場合は、エンドポイント、バケット名、RAM ユーザーの権限を確認してください。

リポジトリ情報の取得

# すべてのリポジトリに関する情報を取得
GET _snapshot
# 特定のリポジトリに関する情報を取得
GET _snapshot/my_backup

スナップショットの作成

全インデックスのスナップショット

PUT _snapshot/my_backup/snapshot_1

これにより、開いているすべてのインデックスに対して snapshot_1 という名前のスナップショットが作成されます。スナップショットは非同期に実行されます。完了を待つには、wait_for_completion=true を追加してください：

PUT _snapshot/my_backup/snapshot_1?wait_for_completion=true

このパラメーターを使用しない場合は、GET _snapshot/my_backup/snapshot_1/_status を実行してスナップショットのステータスを確認してください。 state が SUCCESS の場合、スナップショットは完了しています。

警告

Elasticsearch インスタンスをリリースする前に、スナップショットが完了していることを確認してください。そうしないと、データ損失が発生する可能性があります。

1 つのリポジトリには複数のスナップショットを保持できます。最初のスナップショットはフルバックアップで、それ以降のスナップショットは変更されたデータのみを保存する増分バックアップです。

特定インデックスのスナップショット

PUT _snapshot/my_backup/snapshot_2
{
  "indices": "index_1,index_2",
  "ignore_unavailable": true,
  "include_global_state": false
}

パラメーター	説明
indices	バックアップするインデックスのカンマ区切りリストです。ワイルドカード (`logs-*` など) をサポートします。
ignore_unavailable	`true` の場合、存在しないインデックスを失敗させる代わりにスキップします。
include_global_state	`false` の場合、クラスターのグローバル状態を除外します。データのみのバックアップに推奨します。

スナップショット情報

# すべてのスナップショットを表示
GET _snapshot/my_backup/_all

# 特定のスナップショットを表示
GET _snapshot/my_backup/snapshot_1

# 各インデックスとシャードの統計情報を含む、スナップショットの詳細なステータスを表示
GET _snapshot/my_backup/snapshot_1/_status

スナップショットの削除

DELETE _snapshot/my_backup/snapshot_1

スナップショットが進行中の場合、このコマンドはプロセスを停止し、作成された部分的なデータを削除します。

Kibana Dev Tools または DELETE _snapshot API を使用してスナップショットを削除すると、OSS バケット内の対応するスナップショットファイルはプラグインによって自動的にクリーンアップされます。OSS コンソールから手動で削除する必要はありません。

重要

スナップショットは必ず DELETE _snapshot コマンドで削除してください。OSS コンソールや他のツールからスナップショットファイルを直接削除しないでください。これにより増分バックアップチェーンが壊れ、後続のすべてのスナップショットが破損し、回復不能になる可能性があります。

スナップショットからのリストア

データをリストアする前に：

システムインデックス (プレフィックスが . のインデックス) のリストアは、Kibana にアクセスできなくなる可能性があるため避けてください。
リストアする前に、ターゲットクラスター内に同じ名前の既存インデックスを閉じるか削除してください。さもないと、リストアは失敗します。
クロスリージョンリストアの場合、まず OSS 内のスナップショットデータをターゲットリージョンに移行し、その後ターゲットクラスターにリストアします。コンソールで手動スナップショットを作成する際に [インスタンス] ドロップダウンリストが空の場合、お使いのアカウントでバックアップサービスが有効になっていないか、設定が間違っている可能性があります。クロスリージョンのデータ移行には、OSS のクロスリージョンレプリケーションと手動バックアップを組み合わせて使用します：
1. ソースリージョン (例：杭州) で OSS バケットを作成し、そのバケットにバックアップするように Elasticsearch の手動スナップショットを設定してください。
2. OSS のクロスリージョンレプリケーションルールを設定して、ターゲットリージョン (例：上海) の OSS バケットにデータを同期してください。OSS のデータ移行については、「移行の実装」をご参照ください。
3. ターゲットリージョンに新しい Elasticsearch インスタンスを作成してください。
4. ターゲットの Elasticsearch インスタンスで、ターゲットリージョンの OSS バケットを指すスナップショットリポジトリを登録し、スナップショットをリストアしてください。

ターゲットクラスターでのリポジトリ作成

ターゲットクラスターで、OSS のバックアップ場所を指すリポジトリを作成してください。「スナップショットリポジトリの作成」と同じパラメーターを使用してください。

PUT /_snapshot/my_backup_restore
{
    "type": "oss",
    "settings": {
        "endpoint": "http://oss-cn-hangzhou-internal.aliyuncs.com",
        "access_key_id": "xxxx",
        "secret_access_key": "xxxxxx",
        "bucket": "xxxxxx",
        "compress": true,
        "chunk_size": "500mb",
        "base_path": "snapshot/"
    }
}

特定インデックスのリストア

名前の競合を避けるために、インデックスをリストアして名前を変更します：

POST /_snapshot/my_backup_restore/snapshot_1/_restore
{
 "indices": "index_1",
 "rename_pattern": "index_(.+)",
 "rename_replacement": "restored_index_$1"
}

パラメーター	説明
indices	スナップショットからリストアするインデックスです。他のすべてのインデックスは無視されます。
rename_pattern	リストアするインデックス名に一致する正規表現パターンです。
rename_replacement	名前が変更されたインデックスの置換パターンです。キャプチャグループの参照をサポートします。

システムインデックス以外のリストア

POST _snapshot/my_backup_restore/snapshot_1/_restore
{"indices": "*,-.monitoring*,-.security*,-.kibana*,-.internal.alerts*,-.alerts*","ignore_unavailable": true}

この除外パターンは、一般的なシステムインデックスを対象としています。他のバージョンには、.ds-ilm-history-* や .slo-* などの追加のインデックスが含まれる場合があります。クラスターに応じて調整してください。 8.x の場合は、-.ds* を追加してデータストリームのバッキングインデックスも除外してください。

全インデックスのリストア

POST _snapshot/my_backup_restore/snapshot_1/_restore

_restore API は非同期に実行されます。完了を待つには、wait_for_completion=true を追加してください：

POST _snapshot/my_backup_restore/snapshot_1/_restore?wait_for_completion=true

インデクシングサービスへのリストア

インデクシングサービスインスタンスにリストアする場合は、ignore_index_settings を使用して互換性のない設定をスキップしてください：

POST /_snapshot/my_backup_restore/snapshot_1/_restore
{
  "indices": "index_1",
  "ignore_index_settings": [
    "index.apack.cube.following_index"
  ]
}

スナップショットのリストアステータス

_recovery API を使用してリストアの進捗を監視します。

# 特定インデックスのリストアステータスを確認
GET restored_index_1/_recovery

# すべてのインデックスのリストアステータスを確認 (関連のないシャードが含まれる場合があります)
GET /_recovery/

主要な出力フィールド：

フィールド	説明
type	リカバリタイプです。 `snapshot` はスナップショットからのリカバリを示します。
source	ソースリポジトリとスナップショットです。
percent	リストアの進捗率 (%) です。

リストアのキャンセル

ターゲットインデックスを削除することでリストアをキャンセルします。

DELETE /restored_index_3

重要

これによりリストアが停止し、そのインデックスに関して既にリストアされたすべてのデータが削除されます。

よくある質問

大量のデータを OSS にバックアップするにはどのくらいの時間がかかり、費用はいくらですか？

所要時間の見積もり：参考として、約 80 GB のデータのバックアップには約 30 分かかります。実際の時間は、データ量とインスタンスの帯域幅によって異なります。バックアッププロセスを高速化するには、スナップショットリポジトリ作成時に chunk_size パラメーターを増やすか、インスタンスの帯域幅をアップグレードしてください。
費用の見積もり：バックアップデータを OSS に保存すると、OSS のストレージ料金とトラフィック料金が発生します。実際の費用は、データ量とストレージタイプによって異なります。

スナップショットが失敗した場合や、インデックスが削除できない場合はどうすればよいですか？

スナップショット失敗のトラブルシューティング：
- スナップショットが QpsLimitExceeded で失敗した場合、OSS の QPS スロットリングが発生しています。ノードを再起動してもこの問題は解決しません。バックアップをピーク時間外 (午前 3:00～4:00 など) に再スケジュールするか、OSS に連絡して制限を引き上げてください。
- ノードのメモリプレッシャーまたはガベージコレクション (GC) が原因でスナップショットが失敗した場合は、ノードを再起動してキャッシュされたメモリを解放し、再度スナップショットを作成してください。
スナップショットに関与するインデックスの削除：スナップショット中のインデックスは直接削除できません。インデックスを削除する前に、次のコマンドを実行してスナップショットのステータスを表示してください：
```
GET _snapshot/_status
```
レスポンスで、 state が STARTED である各スナップショットの indices リストを確認してください。リストされているインデックスはバックアップ中です。スナップショットが完了するのを待つか、関連するスナップショットをキャンセルしてからインデックスを削除してください。 state が STARTED のどのスナップショットの indices リストにも表示されないインデックスは、安全に削除できます。

Elasticsearch:手動バックアップとリストア