この記事は、ソフト削除、バージョン管理、またはその両方を有効にするタイミングを判断するのに役立ちます。
BLOB の論理的な削除と BLOB のバージョン管理はどちらも、削除と上書きから保護するのに役立ちます。 これらの機能は、ワークロード、コストの機密性、回復のニーズに応じて、個別に、またはまとめて使用できます。 BLOB とコンテナーを保護するその他の方法については、 データ保護の概要を参照してください。
推奨事項
重要なデータを格納している BLOB ストレージのお客様は、意図しない削除や上書きに対する階層保護のために、論理的な削除とバージョン管理を有効にする必要があります。 論理的な削除により、構成可能な日数の間、データを確実に回復できます。 BLOB のバージョン管理では、以前のバージョンの管理や、以前のバージョンの読み取り、メタデータやプロパティの変更からの回復などの回復オプションを柔軟に管理できます。 適切な情報については、次の詳細を参照してください。
機能の概要
| 特徴 | 保護対象 | 保持期間 | ストレージの動作 | 階層型名前空間 (HNS) に関する考慮事項 |
|---|---|---|---|---|
| ソフトデリート | フラット名前空間アカウントの削除と上書きを行います。 階層型名前空間アカウントの削除。 | 最大 365 日 (構成可能) | 上書きのたびに論理的に削除されたスナップショットを作成します。 削除ごとに論理的に削除された BLOB を作成します。 | ソフト削除は、HNS が有効なアカウントの削除操作のみを保護します。 BLOB の 有効期限の設定 API では、BLOB の論理的な削除機能を使用して、期限切れのファイルを復元することはできません。 |
| バージョン管理 | フラット名前空間アカウントの削除と上書きを行います。 | 無期限 (明示的に削除されるまで) | 書き込みごとに新しいバージョンを作成します。 | HNS が有効なアカウントでは、バージョン管理を使用できません。 |
注
どちらの機能も既定で無効になっており、ストレージ アカウント レベルで有効にする必要があります。
ソフト削除を使用する場合
** 条件を満たす場合はソフト削除を有効にします。
- 誤って削除または上書きされた BLOB を復旧する必要があります。 階層型名前空間が有効なアカウントの場合、ソフトデリートは削除による消失からのみデータを保護し、上書きに対しては保護されません。
- BLOB の復旧には、保有日数の設定と同じ時間制限付きセーフティ ネットが必要です。
考慮事項
すべての上書き操作に対して論理的に削除されたスナップショットが作成されます。 BLOB の論理的な削除では、BLOB のメタデータまたはプロパティを書き込む操作からは保護されません。
すべての削除操作に対して論理的に削除された BLOB が作成されます。 論理的に削除された各 BLOB は、操作時に BLOB のフル サイズで課金されます。
BLOB の一覧表示操作中のパフォーマンスの低下を防ぐため、保有期間中は BLOB ごとに 1,000 個を超える論理的に削除されたスナップショットを使用しないでください。
リテンション期間は 最大 365 日に制限されます。
論理的な削除が有効になっている場合、削除された BLOB、スナップショット、およびバージョンは、構成された論理的な削除の保持期間にわたって保持されます。 完全削除機能が有効になっている場合、論理的に削除されたスナップショットとバージョンは、保持期間が終了する前に完全に削除できます。 保持期間が経過すると、論理的に削除された残りのデータは自動的に完全に削除されます。
論理的な削除が無効になっている場合、すべての削除は永続的ですが、既存の論理的に削除されたデータは保持期間が切れるまで保持されます。
ソフト削除された BLOB の内容には読み取り API を介してアクセスできません。 データにアクセスするには、まず BLOB の削除を取り消す必要があります。
バージョン管理を使用する場合
次の場合にバージョン管理を有効にします。
BLOB に対する変更の完全な履歴を保持する必要があります。 バージョン管理の場合、上書きと削除の両方で以前のバージョンが作成されます。 削除すると現在のバージョンは削除されますが、以前のバージョンは残ります。
メタデータとプロパティの変更を以前のバージョンとして保存する必要があります。
以前の BLOB 状態の長期的または無期限の保持が必要です。
削除を取り消すことなく、以前のバージョンへの迅速なアクセスを維持する必要があります。
考慮事項
各書き込み操作 (Put BLOB、Put Block List、Set Blob Metadata、 および Copy BLOB) は、新しいバージョンの BLOB を作成します。
バージョンは 明示的に削除されるまで保持され、長期的な回復オプションが提供されます。
最適なパフォーマンスを維持し、BLOB 一覧表示操作中のパフォーマンスの低下を防ぐために、 BLOB あたり 1,000 バージョン を超えないようにします。
特定のバージョンはいつでも削除できます。 現在のバージョンと以前のバージョンを削除するには、個別のロールが必要です。 この分離は、間違いを避けるために役立ちます。 同じ ID に、これらのロールの両方を割り当てることができます。 詳細情報。
ライフサイクル管理ポリシーまたは Azure Storage Actions を構成して、バージョンのライフサイクルを制御し、保持条件を定義できます。
階層型名前空間が有効になっているアカウントでは、バージョン管理を使用できません。
両方を使用する場合
次の場合は、論理的な削除とバージョン管理の両方を有効にします。
- 偶発的な削除と上書きの両方に対する包括的な保護が必要です。
- あなたは、階層型データ保護を必要とする規制された環境で動作します。
- バージョンが削除された場合でも、回復オプションを確保する必要があります。
- 以前のバージョンが削除されたときに、一定期間保持される猶予期間（ソフト削除の保持期間）を作成したい。
考慮事項
バージョン管理が有効になっている場合、現在のバージョンを削除すると、以前のバージョンになります。 論理的な削除が有効になっている場合、以前のバージョンを削除すると、論理的に削除された以前のバージョンになります。 (詳細はこちら)
ソフト削除の保持期間は、以前のバージョンの削除にのみ適用されます。 保持期間の前にソフト削除バージョンを完全に削除する場合は、次の手順を確認してください。
最適なパフォーマンスを維持し、BLOB 一覧表示操作中のパフォーマンスの低下を防ぐために、 BLOB あたり 1,000 バージョン を超えないようにします。
各機能は、異なる方法でデータを保持します。 バージョン管理と論理的な削除に異なる保持期間を設定して、コストとデータ損失のリスクのバランスを取ることができます。
いずれも使用しない場合の選択方法
次の場合は、両方の機能を無効にすることができます。
- アプリケーションには、独自のバックアップと回復のメカニズムがあります。
- コストの制約が厳しく、偶発的なデータ損失のリスクが低い。
- データは一時的なデータまたはテスト データであり、保護は必要ありません。
削除後の BLOB アクセシビリティ
アカウントで論理的な削除、バージョン管理、またはその両方が有効になっているかどうかに関係なく、このセクションでは、BLOB が削除された後にデータにアクセスする方法について説明します。
バージョン管理が有効になっている場合は、以前のバージョンを読み取るバージョン ID を指定する必要があります。 BLOB の コピー 操作を使用して、以前のバージョンを新しい現在のバージョンにコピーします。
ソフト削除が有効になっている場合は、BLOB の削除を取り消す必要があります。
バージョン管理と論理的な削除が有効になっていて、アクセスする以前のバージョンが論理的に削除されている場合は、最初に BLOB の削除を取り消す必要があります。 Undelete Blob 操作では、ソフト削除されたすべてのバージョンの BLOB が常に復元されます。 次に、 BLOB のコピー 操作を使用して、以前のバージョンを新しい現在のバージョンにコピーできます。
コストに関する考慮事項
頻繁に上書きされるデータに対して論理的な削除またはバージョン管理を有効にすると、ストレージ容量の料金が増加し、BLOB を一覧表示するときの待機時間が長くなる可能性があります。 Put Block と Put Block List を使用したブロック レベルの更新により、ストレージ コストを削減できます。 BLOB、バージョン、またはスナップショットの層に変更を加えない場合は、その BLOB のバージョンとスナップショット全体の一意のデータ ブロックに対して課金されます。 BLOB、バージョン、およびスナップショットが完全に削除されるまで、アクティブデータに課金され続けます。 詳細情報