ブロック BLOB のポイントインタイム リストア
ポイントインタイム リストアでは、ブロック BLOB データを以前の状態に復元できるようにすることで、誤った削除や破損を防ぐことができます。 ポイントインタイム リストアは、ユーザーまたはアプリケーションによって誤ってデータが削除された場合や、アプリケーション エラーによってデータが破損した場合に役立ちます。 また、ポイントインタイム リストアでは、さらにテストを実行する前にデータセットを既知の状態に戻す必要があるテスト シナリオも有効になります。
ポイントインタイム リストアは、標準パフォーマンス レベルでのみ、汎用 v2 ストレージ アカウントに対してサポートされています。 ポイントインタイム リストアでは、ホットおよびクール アクセス層のデータのみを復元できます。 階層型名前空間を持つアカウントでは、ポイントインタイム リストアはまだサポートされていません。
ストレージ アカウントのポイントインタイム リストアを有効にする方法については、「ブロック BLOB データに対してポイントインタイム リストアを実行する」を参照してください。
ポイントインタイム リストアのしくみ
ポイントインタイム リストアを有効にするには、ストレージ アカウントの管理ポリシーを作成し、保有期間を指定します。 保有期間中は、ブロック BLOB を現在の状態から前の時点の状態に復元できます。
ポイントインタイム リストアを開始するには、Restore Blob Ranges 操作を呼び出し、復元ポイントを UTC 時刻で指定します。 復元するコンテナーおよび BLOB の名前の辞書式範囲を指定することも、範囲を省略して、ストレージ アカウントのすべてのコンテナーを復元することもできます。 復元操作ごとに最大 10 個の辞書式範囲がサポートされます。
Azure Storage では、要求された復元ポイント (UTC 時刻で指定) から現在の時点までの間で、指定された BLOB に対して行われたすべての変更が分析されます。 復元操作はアトミックであるため、すべての変更を完全に復元できるか、または失敗します。 復元できない BLOB がある場合、操作は失敗し、影響を受けるコンテナーに対する読み取りと書き込み操作が再開されます。
次の図は、ポイントインタイム リストアがどのように機能するかを示しています。 1 つ以上のコンテナーまたは BLOB 範囲が n 日前のその状態に復元されます。ここでは、n はポイントインタイム リストアに定義された保有期間の範囲以下になります。 この効果は、保有期間中に発生した書き込みと削除の操作を元に戻すことです。
ストレージ アカウントで一度に実行できる復元操作は 1 つだけです。 復元操作は実行中に取り消すことはできませんが、最初の操作を元に戻すために 2 回目の復元操作を実行できます。
Restore Blob Ranges 操作では、操作を一意に識別する復元 ID が返されます。 ポイントインタイム リストアの状態を確認するには、Restore Blob Ranges 操作から返された復元 ID を使用して Get Restore Status 操作を呼び出します。
重要
復元操作を実行すると、Azure Storage では操作中、復元される範囲内の BLOB に対するデータ操作がブロックされます。 読み取り、書き込み、および削除の各操作がプライマリ ロケーションでブロックされます。 このため、Azure portal でのコンテナーの一覧表示などの操作は、復元操作の実行中に予期したとおりに実行されない場合があります。
ストレージ アカウントが geo レプリケートされている場合は、復元操作中にセカンダリ ロケーションからの読み取り操作を続行できます。
注意事項
ポイントインタイム リストアでは、ブロック BLOB に影響する操作に対する復元のみがサポートされます。 コンテナーに影響する操作は復元できません。 たとえば、Delete Container 操作を呼び出してストレージ アカウントからコンテナーを削除した場合、そのコンテナーはポイントインタイム リストア操作で復元できません。 後で復元が必要になる可能性がある場合は、コンテナー全体を削除するのではなく、個々の BLOB を削除してください。
ポイントインタイム リストアの前提条件
ポイントインタイム リストアを有効にするには、ポイントインタイム リストアで次の Azure Storage 機能が有効になっている必要があります。
データ保護に関する Microsoft の推奨事項の詳細については、「データ保護の概要」を参照してください。
注意事項
ストレージ アカウントの BLOB のバージョン管理を有効にすると、そのアカウント内の BLOB に対するすべての書き込み操作で新しいバージョンが作成されます。 このため、BLOB のバージョン管理を有効にすると、追加のコストが発生する可能性があります。 コストを最小限に抑えるには、ライフサイクル管理ポリシーを使用して、古いバージョンを自動的に削除します。 ライフサイクル管理の詳細については、「Azure Blob Storage アクセス層の自動化によるコストの最適化」を参照してください。
ポイントインタイム リストアの保有期間
ストレージ アカウントのポイントインタイム リストアを有効にする場合は、保有期間を指定します。 ストレージ アカウントのブロック BLOB は、保有期間中に復元できます。
保有期間は、ポイントインタイム リストアを有効にした数分後に開始されます。 BLOB を、保持期間が始まる前の状態に復元することはできないことに留意してください。 たとえば、5 月 1 日に保持期間を 30 日に設定してポイントインタイム リストアを有効にした場合、5 月 15 日には最大 15 日間まで復元できます。 6 月 1 日には 1 日から 30 日間までのデータを復元できます。
ポイントインタイム リストアの保有期間は、論理的な削除に指定された保有期間よりも 1 日以上短くする必要があります。 たとえば、論理的な削除の保持期間が 7 日間に設定されている場合、ポイントインタイム リストアの保持期間は 1 日から 6 日間の範囲になります。
Note
ポイントインタイム リストアに指定する保持期間は、BLOB バージョンの保持には影響しません。 BLOB バージョンは、明示的に削除されるまで保持されます。 古いバージョンを削除または階層化してコストを最適化するには、ライフサイクル管理ポリシーを作成します。 詳細については、「データ ライフサイクルを自動管理してコストを最適化する」を参照してください。
一連のデータの復元にかかる時間は、復元期間中に行われた書き込み操作と削除操作の数に基づきます。 たとえば、100 万の BLOB があるアカウントで毎日 3,000 の BLOB が追加され、毎日 1,000 の BLOB が削除される場合、過去 30 日間のポイントまで復元するのに約 2 時間必要になります。 過去 90 日間の保持期間と復元は、このような変更率のアカウントには推奨されません。
ポイントインタイム リストアのアクセス許可
復元操作を開始するには、クライアントはストレージ アカウントのすべてのコンテナーに対する書き込みアクセス許可を持っている必要があります。 Microsoft Entra ID で復元操作を承認するアクセス許可を付与するには、ストレージ アカウント、リソースグループ、またはサブスクリプションのレベルでセキュリティ プリンシパルにストレージ アカウント共同作成者ロールを割り当てます。
制限事項と既知の問題
ブロック BLOB のポイントインタイム リストアには、次の制限事項と既知の問題があります。
- ポイントインタイム リストア操作の一部として復元できるのは、標準の汎用 v2 ストレージ アカウントのブロック BLOB のみです。 追加 BLOB、ページ BLOB、Premium ブロック BLOB は復元されません。
- 保持期間中にコンテナーを削除した場合、そのコンテナーは、ポイントインタイム リストア操作では復元されません。 復元しようとしている BLOB 範囲に、削除されたコンテナー内の BLOB が含まれている場合、ポイントインタイム リストア操作は失敗します。 コンテナーを削除から保護する方法については、「コンテナーの論理的な削除」を参照してください。
- 永続的な削除を使用して、ポイントインタイム リストアの保有期間中に論理的に削除されたバージョンの BLOB を消去した場合、復元操作でその BLOB を適正に復元できない場合があります。
- 現在の時点から復元ポイントまでの間にホット層とクール層の間で BLOB が移動した場合、BLOB は以前の層に復元されます。
- アーカイブ層でのブロック BLOB の復元はサポートされていません。 たとえば、ホット層の BLOB が 2 日前にアーカイブ層に移動され、復元操作によって 3 日前の時点に復元された場合、BLOB はホット層に復元されません。 アーカイブされた BLOB を復元するには、最初にアーカイブ層の外に移動します。 詳細については、「アーカイブからの BLOB のリハイドレートの概要」を参照してください。
- 部分的な復元操作はサポートされていません。 そのため、コンテナーにアーカイブされた BLOB がある場合、Archive レベルのブロック BLOB の復元はサポートされていないので、復元操作全体が失敗します。
- 不変性ポリシーが構成されている場合、復元操作を開始できますが、不変性ポリシーによって保護されている BLOB は変更されません。 この場合の復元操作では、指定された日時まで一貫性のある状態に復元される結果になりません。
- Put Block または Put Block from URL を使用してアップロードされたが、Put Block List を使用してコミットされていないブロックは、BLOB の一部ではないため、復元操作の一部としては復元されません。
- アクティブなリースを持つ BLOB が復元する範囲に含まれている場合や、リースされた BLOB の現在のバージョンが PITR に指定されたタイムスタンプ時点の前のバージョンとは異なる場合、復元操作はアトミックに失敗します。 復元操作を開始する前に、アクティブなリースを中断することをお勧めします。
- ストレージ アカウントで顧客が管理するフェールオーバーを実行すると、そのストレージ アカウントの可能な限り最も早い復元ポイントがリセットされます。 詳細については、「ポイントインタイム リストア」を参照してください。
- スナップショットは、復元操作の一環として作成または削除されません。 ベース BLOB のみが以前の状態に復元されます。
- ポイントインタイム リストアは、Azure Data Lake Storage による階層型名前空間や操作ではサポートされていません。
- ストレージ アカウントの AllowedCopyScope プロパティが、コピー スコープを同じ Microsoft Entra テナントまたは仮想ネットワークに制限するように設定されている場合、ポイントインタイム リストアはサポートされません。 詳しくは、「コピー操作の許可されるスコープ (プレビュー) について」を参照してください。
- ストレージ アカウントまたはアカウント内のコンテナーでバージョン レベルの不変性が有効になっている場合、ポイントインタイム リストアはサポートされません。 バージョンレベルの不変性について詳しくは、「BLOB バージョンに対する不変性ポリシーを構成する」を参照してください。
重要
ブロック BLOB を 2020 年 9 月 22 日より前の時点に復元すると、ポイントインタイム リストアのプレビュー制限が有効になります。 一般公開されているポイントインタイム リストア機能を利用するには、2020 年 9 月 22 日以降の復元ポイントを選択することをお勧めします。
機能サポート
Data Lake Storage Gen2、Network File System (NFS) 3.0 プロトコル、または SSH ファイル転送プロトコル (SFTP) を有効にすると、この機能のサポートが影響を受ける場合があります。 これらの機能のいずれかを有効にしている場合は、「Azure Storage アカウントでの Blob Storage 機能のサポート」 を参照して、この機能のサポートを評価してください。
価格と課金
ポイントインタイム リストアを有効にするのに料金はかかりません。 ただし、ポイントインタイム リストアを有効にすると、BLOB のバージョン管理、論理的な削除、変更フィードも有効になり、それぞれに追加料金が発生することがあります。
ポイントインタイム リストア操作を実行するための課金は、復元で処理された変更フィード データの量に基づきます。 また、復元プロセスに関連するすべてのストレージ トランザクションに対して課金されます。
ポイントインタイム リストアの価格の詳細については、「ブロック BLOB の価格」を参照してください。