Amazon Timestream for LiveAnalytics に類似した機能をご希望の場合は Amazon Timestream for InfluxDB をご検討ください。リアルタイム分析に適した、シンプルなデータインジェストと 1 桁ミリ秒のクエリ応答時間を特徴としています。詳細については、[こちら](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)を参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Timestream テーブルのバックアップと復元: 仕組み
Amazon Timestream テーブルのバックアップを作成できます。このセクションでは、バックアップおよび復元プロセス中の概要について示します。
**Topics**
+ [バックアップ](#backups-backups)
+ [復元](#backups-restores)
## バックアップ
オンデマンドバックアップの機能を使うことで、Amazon Timestream for LiveAnalytics テーブルの完全バックアップを作成することができます。このセクションでは、バックアップおよび復元プロセス中の概要について示します。
Timestream データのバックアップは、テーブルの詳細度で作成できます。選択したテーブルのバックアップは、Timestream コンソール、 AWS Backup コンソール、SDK、または CLI を使用して開始できます。バックアップは非同期で作成され、バックアップ開始時刻までのテーブル内のデータすべてがバックアップに含まれます。ただし、バックアップの最中にテーブルに取り込まれるデータの一部がバックアップに含まれる可能性もあります。データを保護するには、1 回限りのオンデマンドバックアップを作成するか、テーブルの定期的なバックアップをスケジュールします。
バックアップの最中は以下を行うことができません。
+ バックアップオペレーションの一時停止またはキャンセル。
+ バックアップのソーステーブルの削除。
+ テーブルのバックアップ中におけるテーブルのバックアップの無効化。
設定が完了すると、 は自動バックアップスケジュール、保持管理、ライフサイクル管理 AWS Backup を提供し、カスタムスクリプトや手動プロセスが不要になります。詳細については、「[AWS Backup デベロッパーガイド](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)」を参照してください。
Timestream for LiveAnalytics のバックアップはすべて増分的です。つまり、テーブルの最初のバックアップは完全バックアップで、同じテーブルの後続のバックアップは増分バックアップとなり、最後のバックアップ以降にデータに施された変更のみがコピーされます。Timestream for LiveAnalytics のデータはパーティションのコレクションに保存されるため、新しいデータの取り込みまたは最後のバックアップ以降に既存データに施された更新によって変更されたすべてのパーティションは、後続のバックアップ中にコピーされます。
Timestream for LiveAnalytics コンソールを使用している場合、アカウント内のすべてのリソース用に作成されたバックアップが **[バックアップ]** タブに表示されます。また、バックアップは **[テーブル]** の詳細にも表示されます。
## 復元
テーブルは、Timestream for LiveAnalytics コンソール、または AWS Backup コンソール、SDK、CLI AWS から復元できます。バックアップからデータ全体を復元したり、テーブルの保持設定で選択したデータを復元するように設定したりすることができます。復元を実行する際に、テーブルに対して次の設定を行えます。
+ Database Name
+ テーブル名
+ メモリストアの保持
+ マグネティックストアの保持
+ マグネティックストレージの書き込みの有効化
+ S3 エラーログの場所 (オプション)
+ バックアップの復元時に AWS Backup が引き受ける IAM ロール
上記の設定は、ソーステーブルに依存しません。バックアップ内のすべてのデータを復元するには、新しいテーブル設定を、メモリストアの保持期間とマグネティックストアの保持期間の合計が最も古いタイムスタンプと現在との差よりも大きくなるように設定することが推奨されます。復元する増分バックアップを選択すると、すべてのデータ (増分のデータと基の全データ) が復元されます。復元が成功するとテーブルはアクティブ状態になり、復元されたテーブルに対して取り込みやクエリの操作を実行できます。ただし、これらの操作は復元の最中は実行できません。復元が完了すると、テーブルはアカウント内の他のテーブルに似たものになります。
**Example バックアップからすべてのデータを復元する**
この例では次を前提としています。
*最も古いタイムスタンプ* – `August 1, 2021 0:00:00`
+ *現在* – `November 9, 2022 0:00:00`
バックアップから全データを復元するには、次のように値を入力して比較します。
1. **[メモリストアの保持期間]** と **[マグネティックストアの保持期間]** を入力します。例えば、次のような値だと仮定します。
+ *[メモリストアの保持期間]* – 12 時間
+ *[マグネティックストアの保持期間]* – 500 日間
1. **[メモリストアの保持期間]** と **[マグネティックストアの保持期間]** の合計を計算します。
```
12 hours + (500 * 24 hours) =
12 hours + 12,000 hours =
12,012 hours
```
1. **[最も古いタイムスタンプ]** と現在の差を計算します。
```
November 9, 2022 0:00:00 - August 1, 2021 0:00:00 =
465 days =
465 * 24 hours =
11,160 hours
```
1. 上記 2 の保持期間の合計が 3 の時間差よりも大きいことを確認します。必要に応じて保持時間を調整します。
```
12,012 > 11,160
true
```
**Example 一部のデータをバックアップから復元するには**
この例では次を前提としています。
+ *現在* – `November 9, 2022 0:00:00`
選択したデータのみをバックアップから復元するには、次のように値を入力して比較します。
1. 必要とする最も早いタイムスタンプを特定します。ここでは `December 4, 2021 0:00:00` と仮定します。
1. 必要とする最も早いタイムスタンプと現在との差を計算します。
```
November 9, 2022 0:00:00 - December 4, 2021 0:00:00 =
340 days =
340 * 24 hours =
8,160 hours
```
1. 必要な値を **[メモリストアの保持期間]** に入力します。ここでは 12 時間と入力します。
1. この値を 2 で特定した値から引きます。
```
8,160 hours - 12 hours =
8148 hours
```
1. この値を **[マグネティックストアの保持期間]** に入力します。
Timestream for LiveAnalytics テーブルデータのバックアップを別の AWS リージョンにコピーし、その新しいリージョンに復元できます。 AWS 商用リージョンと AWS GovCloud (米国) リージョン間でバックアップをコピーして復元できます。送信元リージョンからコピーしたデータと、送信先リージョンの新しいテーブルに復元したデータに対してのみ料金が発生します。
テーブルを復元したら、復元したテーブルで以下を手動で設定します。
+ AWS Identity and Access Management (IAM) ポリシー
+ タグ
+ スケジュールされたクエリ
復元時間は、テーブルの設定に直接関連します。これには、テーブルのサイズ、基盤となるパーティションの数、メモリストアに復元されたデータの量およびその他の変数が含まれます。ディザスタリカバリを計画する際のベストプラクティスは、平均復元完了時間を定期的に記録し、これらの時間が目標復旧時間 (RTO) 全体にどのように影響するかを確認することです。
すべてのバックアップおよび復元コンソールおよび API アクションは、ログ記録、継続的なモニタリング、監査のために AWS CloudTrail にキャプチャおよび記録されます。