

Amazon Timestream for LiveAnalytics に類似した機能をご希望の場合は Amazon Timestream for InfluxDB をご検討ください。リアルタイム分析に適した、シンプルなデータインジェストと 1 桁ミリ秒のクエリ応答時間を特徴としています。詳細については、[こちら](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)を参照してください。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# の使用 AWS Backup
<a name="backups"></a>

Amazon Timestream for LiveAnalytics のデータ保護機能は、規制を順守しビジネス継続性の要件を満たすのに役立つフルマネージドのソリューションです。この機能は、バックアップの作成 AWS Backup、移行、復元、削除を簡素化し、レポートと監査を改善するように設計された統合バックアップサービスである とのネイティブ統合によって実現されます。との統合により AWS Backup、フルマネージド型のポリシー駆動型の一元化されたデータ保護ソリューションを使用して、変更不可能なバックアップを作成し、Timestream および でサポートされている他の AWS サービスにまたがるアプリケーションデータのデータ保護を一元管理できます AWS Backup。

機能を使用するには、 AWS Backup が Timestream リソースを保護するように[オプトイン](https://docs.aws.amazon.com/aws-backup/latest/devguide/service-opt-in.html)する必要があります。オプトインの選択は特定のアカウントと AWS リージョンに適用されるため、同じアカウントを使用して複数のリージョンにオプトインする必要がある場合があります。 AWS Backup の詳細については、「[AWS Backup デベロッパーガイド](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)」を参照してください。

で利用できるデータ保護機能 AWS Backup には以下が含まれます。

**定期的なバックアップ** – バックアッププランを使用して、Timestream for LiveAnalytics テーブルの定期的に予定されたバックアップを設定できます。

**クロスアカウントコピーとクロスリージョンコピー** — バックアップを別の AWS リージョンまたはアカウントの別のバックアップボールトに自動的にコピーできるため、データ保護要件をサポートできます。

**コールドストレージ階層化** – バックアップを削除したり古いストレージに移行したりする、ライフサイクルルールを実施するようにバックアップを設定できます。これにより、バックアップコストを最適化できます。

**タグ** – 請求およびコスト配分のために、バックアップに自動的にタグを付けることができます。

**暗号化** – バックアップデータは AWS Backup ボールトに保存されます。これにより、Timestream for LiveAnalytics テーブル暗号化キーから独立した AWS KMS キーを使用して、バックアップを暗号化および保護できます。

**WORM モデルを使用した安全なバックアップ** – AWS Backup Vault Lock を使用することで、バックアップの Write-Once-Read-Many (WORM) 設定を有効にすることができます。 AWS Backup ボールトロックを使用すると、不注意または悪意のある削除オペレーション、バックアップ保持期間の変更、ライフサイクル設定の更新からバックアップを保護する防御レイヤーを追加できます。詳細については、[AWS Backup Vault Lock](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html) を参照してください。

データ保護機能はすべてのリージョンで利用できます。この機能の詳細については、「[AWS Backup デベロッパーガイド](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)」を参照してください。

# Timestream テーブルのバックアップと復元: 仕組み
<a name="backups-how-it-works"></a>

Amazon Timestream テーブルのバックアップを作成できます。このセクションでは、バックアップおよび復元プロセス中の概要について示します。

**Topics**
+ [バックアップ](#backups-backups)
+ [復元](#backups-restores)

## バックアップ
<a name="backups-backups"></a>

オンデマンドバックアップの機能を使うことで、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 コンソールを使用している場合、アカウント内のすべてのリソース用に作成されたバックアップが **[バックアップ]** タブに表示されます。また、バックアップは **[テーブル]** の詳細にも表示されます。

## 復元
<a name="backups-restores"></a>

テーブルは、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 にキャプチャおよび記録されます。

# Amazon Timestream テーブルのバックアップの作成
<a name="backups-creating"></a>

このセクションでは、Amazon Timestream のオンデマンド AWS Backup バックアップとスケジュールされたバックアップを有効にして作成する方法について説明します。

**Topics**
+ [を有効に AWS Backup して LiveAnalytics データの Timestream を保護する](#backups-enabling)
+ [オンデマンドバックアップの作成](#backups-on-demand)
+ [スケジュールバックアップ](#backups-scheduled)

## を有効に AWS Backup して LiveAnalytics データの Timestream を保護する
<a name="backups-enabling"></a>

 AWS Backup を LiveAnalytics の Timestream で使用するには、 を有効にする必要があります。

Timestream for LiveAnalytics コンソール AWS Backup で を有効にするには、次の手順を実行します。

1.  [AWS マネジメントコンソール](https://console.aws.amazon.com/timestream)にサインインします。

1. Timestream for LiveAnalytics ダッシュボードページの上部にポップアップバナーが表示され、 AWS Backup が Timestream for LiveAnalytics データをサポートできるようになります。表示されない場合は、ナビゲーションペインで **[バックアップ]** を選択します。

1. **[バックアップ]** ウィンドウに、 AWS Backupを有効にするためのバナーが表示されます。**[有効化]** を選択します。

   によるデータ保護 AWS Backup が Timestream for LiveAnalytics テーブルで使用できるようになりました。

から を有効にするには AWS Backup、 コンソールを介してプログラムで を有効にする AWS Backup ドキュメントを参照してください。

有効にした後に Timestream for LiveAnalytics データの保護 AWS Backup を無効にする場合は、 AWS Backup コンソールからログインし、トグルを左に移動します。

 AWS Backup 機能を有効または無効にできない場合は、 AWS 管理者がこれらのアクションを実行する必要がある場合があります。

## オンデマンドバックアップの作成
<a name="backups-on-demand"></a>

Timestream for LiveAnalytics テーブルのオンデマンドバックアップを作成するには、次の手順に従います。

1. [AWS マネジメントコンソール](https://console.aws.amazon.com/timestream)にサインインします。

1. コンソールの左側のナビゲーションペインで、**[Backups]** (バックアップ) を選択します。

1. **[オンデマンドバックアップを作成]** を選択します。

1. バックアップウィンドウで設定の選択を継続します。

1. バックアップを今すぐ作成するか、バックアップをすぐに開始するか、バックアップウィンドウを選択してバックアップを開始するか、いずれかを選択します。

1. バックアップのライフサイクル管理ポリシーを選択します。バックアップデータをコールドストレージに移行します。ここでのバックアップの保持期間は 90 日間以上です。バックアップに必要な保持期間を設定できます。既存のボールトを選択するか、**新しいバックアップボールトの作成**を選択して AWS Backup コンソールに移動し、新しいバックアップボールトを作成します。＜ここで新しいバックアップボールトを作成する際のドキュメントリンク>

1. 適切な IAM ロールを選択します。

1. オンデマンドバックアップに 1 つ以上のタグを割り当てる場合は、**[キー]** とオプションの **[値]**] を入力して、**[タグを追加]** を選択します。

1. [オンデマンドバックアップを作成] を選択します。**[バックアップ]** ページに移動します。ジョブのリストが表示されます。

1. バックアップするリソースの [**バックアップジョブ ID**] を選択すると、そのジョブの詳細が表示されます。

## スケジュールバックアップ
<a name="backups-scheduled"></a>

バックアップをスケジュールする方法は、[スケジュールされたバックアップの作成](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-a-scheduled-backup.html)に関するドキュメントを参照してください。

# Amazon Timestream テーブルのバックアップの復元
<a name="backups-restoring"></a>

このセクションでは、Amazon Timestream テーブルのバックアップを復元する方法について説明します。

**Topics**
+ [から LiveAnalytics テーブルの Timestream を復元する AWS Backup](#backups-restoring-from)
+ [Timestream for LiveAnalytics テーブルを別のリージョンまたはアカウントに復元する](#backups-restoring-to)

## から LiveAnalytics テーブルの Timestream を復元する AWS Backup
<a name="backups-restoring-from"></a>

Timestream for LiveAnalytics コンソール AWS Backup から Timestream for LiveAnalytics テーブルを復元するには、次の手順に従います。

1. [AWS マネジメントコンソール](https://console.aws.amazon.com/timestream)にサインインします。

1. コンソールの左側のナビゲーションペインで、**[Backups]** (バックアップ) を選択します。

1. リソースを復元するには、リソースの復旧ポイント ID の横にあるラジオボタンをクリックします。ペインの右上隅にある **[復元]** を選択します。

1. テーブルの設定、つまり **[データベース名]** と **[テーブル名]** を入力します。復元したテーブルの名前は、復元元のテーブル名とは違う名前にする必要があります。

1. メモリストアとマグネティックストアの保持に関する設定を行います。

1. **復元ロール**で、この復元のために AWS Backup が引き受ける IAM ロールを選択します。

1. **[バックアップを復元]** を選択します。ページ上部のメッセージには、復元ジョブに関する情報が表示されます。

**注記**  
バックアップ全体の復元に対しては、設定したメモリおよびマグネティックストアの保持期間に関係なく料金が請求されます。ただし、復元の実行後は、復元したテーブルには設定した保持期間内のデータのみが含まれます。

## Timestream for LiveAnalytics テーブルを別のリージョンまたはアカウントに復元する
<a name="backups-restoring-to"></a>

Timestream for LiveAnalytics テーブルを別のリージョンまたはアカウントに復元するには、まずその新しいリージョンまたはアカウントにバックアップをコピーする必要があります。別のアカウントにコピーするには、まずそのアカウントからアクセス許可を付与される必要があります。Timestream for LiveAnalytics のバックアップを新しいリージョンまたはアカウントにコピーした後、前のセクションのプロセスを使用して復元できます。

# Amazon Timestream テーブルのバックアップをコピーする
<a name="backups-copying"></a>

現在のバックアップのコピーを作成できます。バックアップは、オンデマンドで複数の AWS アカウントまたは AWS リージョンにコピーすることも、スケジュールされたバックアッププランの一部として自動的にコピーすることもできます。クロスリージョンレプリケーションは、ビジネス継続性またはコンプライアンス要件があり、本番稼働用データから最小限の距離だけ離してバックアップを保存する場合に特に役立ちます。

クロスアカウントバックアップは、運用上またはセキュリティ上の理由からバックアップを組織内の 1 つまたは複数の AWS アカウントに確実にコピーする必要がある場合に便利です。元のバックアップを誤って削除してしまった場合は、コピー先のアカウントからコピー元のアカウントにバックアップをコピーし復元できます。これを行うには、Organizations サービスの同じ組織に属する 2 つのアカウントと、それらのアカウントに必要とされるアクセス許可が必要になります。増分バックアップを別のアカウントまたはリージョンにコピーすると、関連する全バックアップもコピーされます。

特に指定しない限り、コピーにはバックアップ元の設定が継承されます。1 つ例外があります。新しいコピーで有効期限なしを指定した場合です。この設定では、新しいコピーはソースの有効期限を継承します。新しいバックアップコピーを永続的なコピーにする場合は、ソースバックアップを期限切れにならないように設定するか、新しいコピーの作成から 100 年後を有効期限に指定します。

Timestream コンソールからバックアップをコピーするには、次の手順に従います。

1. [AWS マネジメントコンソール](https://console.aws.amazon.com/timestream)にサインインします。

1. コンソールの左側のナビゲーションペインで、**[Backups]** (バックアップ) を選択します。

1. リソースの復元ポイント ID の横にあるボタンをクリックします。ペインの右上で **[アクション]** を選択し、次に **[コピー]** を選択します。

1. ** AWS 「バックアップに進む**」を選択し、[クロスアカウントバックアップ](https://docs.aws.amazon.com/aws-backup/latest/devguide/cross-region-backup.html)の手順に従います。

アカウントとリージョン間でのオンデマンドバックアップとスケジュールされたバックアップのコピーは、現在 Timestream for LiveAnalytics コンソールではネイティブにサポートされていないため、オペレーションを実行する AWS Backup には に移動する必要があります。

# バックアップの削除
<a name="backups-deleting"></a>

このセクションでは、Timestream for LiveAnalytics テーブルのバックアップを復元する方法について説明します。

Timestream コンソールからバックアップを削除するには、次の手順に従います。

1. [AWS マネジメントコンソール](https://console.aws.amazon.com/timestream)にサインインします。

1. コンソールの左側のナビゲーションペインで、**[Backups]** (バックアップ) を選択します。

1. リソースの復元ポイント ID の横にあるボタンをクリックします。ペインの右上で **[アクション]** を選択し、次に **[削除]** を選択します。

1. ** AWS 「バックアップに進む**」を選択し、「バックアップの削除」の[「バックアップを削除する](https://docs.aws.amazon.com/aws-backup/latest/devguide/deleting-backups.html)」の手順に従います。

**注記**  
増分のバックアップを削除した場合は増分バックアップのみが削除され、元の全バックアップは削除されません。

# クォータと制限
<a name="backups-limits"></a>

AWS Backup は、バックアップをリソースごとに 1 つの同時バックアップに制限します。したがって、リソースに対してスケジュールされたバックアップまたはオンデマンドバックアップを追加でリクエストすると、キューに入れられ、既存のバックアップジョブが完了した後に処理が開始されます。バックアップのジョブがバックアップウィンドウ内で開始または完了しない場合、そのリクエストは失敗します。 AWS Backup 制限の詳細については、[AWS 「 Backup デベロッパーガイド」の「Backup Limits](https://docs.aws.amazon.com/aws-backup/latest/devguide/aws-backup-limits.html)」を参照してください。 AWS 

バックアップを作成するときは、アカウントごとに最大 4 つの同時バックアップを実行できます。同様に、実行できる同時復元はアカウントごとに 1 つです。5 つ以上のバックアップジョブを同時に開始すると、4 つのバックアップジョブのみが開始され、残りのジョブは定期的に再試行されます。バックアップジョブを開始すると、設定したバックアップウィンドウの期間内にジョブが完了しない場合、そのジョブは失敗します。失敗したバックアップジョブがオンデマンドバックアップであった場合、そのバックアップは再試行できます。スケジュールされたバックアップであった場合、そのジョブは次回のスケジュールで試行されます。