オブジェクトの過去バージョンを自動的に維持するために、Blobのバージョン管理を有効にすることができます。 Blobのバージョン管理を有効にすると、Blobの古いバージョンにアクセスして、変更や削除されたデータを復元できます。
注意事項
ストレージ アカウントの BLOB のバージョン管理を有効にすると、そのアカウント内の BLOB に対するすべての書き込み操作で新しいバージョンが作成されます。 このため、ブロブのバージョン管理を有効にすると追加コストが発生する可能性があります。 コストを最小限に抑えるために、 ライフサイクル管理 ポリシーや ストレージアクション タスクを使って、過去のバージョンを自動的に削除します。
推奨されるデータ保護の構成
Blobのバージョン管理は、いくつかのデータ保護機能の一つです。 適切な機能や機能の組み合わせを選ぶことは、あなたの作業負荷や何から保護するかによって異なります。 Microsoftのデータ保護に関する推奨事項については、「データ保護概要」をご覧ください。
バージョン対スナップショット
ブロブバージョンはスナップショットに似ていますが、作成方法や最適な用途が異なります。 バージョンの作成は自動的にシステムによって管理されます。Azure Storageは、Blobのバージョン管理を有効にすると、書き込みや削除のたびに新しいバージョンを作成し、アプリケーションロジックは不要です。 スナップショットは手動でアプリケーション主導型です。アプリケーションが必要だと判断した時点で、明示的に特定時点のコピーを作成します。
偶発的または悪意のある上書きや削除を防ぐための自動的かつ継続的な保護が必要な場合は、バージョン管理を活用しましょう。 計画された更新前の既知のチェックポイントなど、意図的なポイントインタイムコピーが必要な場合にスナップショットを使いましょう。 Microsoftは、バージョン管理が有効になったらブロックブロブのスナップショットを取るのをやめることを推奨しています。
BLOB のバージョン管理のしくみ
バージョンによって、指定された時点での BLOB の状態がキャプチャされます。 各バージョンにはバージョンIDがあります。 ストレージ アカウントで BLOB のバージョン管理を有効にすると、Azure Storage は、ブロブを最初に作成したときと、その後ブロブを変更するたびに、一意の ID を持つ新しいバージョンを自動的に作成します。
バージョン ID によって、現在のバージョンまたは以前のバージョンを識別することができます。 ブロブは一度に一つのバージョン、つまり現在の状態だけを持てます。 ブロブは複数の以前のバージョンを持つことができます。
新しい BLOB を作成すると、1 つのバージョンが存在することになり、そのバージョンが現在のバージョンになります。 既存の BLOB を変更すると、現在のバージョンが以前のバージョンになります。 更新された状態を取り込むために新しいバージョンが作成され、その新しいバージョンが現在のバージョンになります。 ある BLOB を削除すると、その BLOB の現在のバージョンが前のバージョンになり、現在のバージョンは存在しなくなります。 その BLOB の以前のすべてのバージョンが保持されます。
以下の図は、書き込み操作でバージョンがどのように作成されるか、また以前のバージョンが現在のバージョンにどのように昇格するかを示しています。
以前のブロブのバージョンは不変であり、内容やメタデータを変更できません。
重要
BLOB ごとに多数のバージョンがあると、BLOB の一覧表示操作の待機時間が長くなる可能性があります。 Microsoftは、1つのブロブにつき1,000バージョン未満の維持を推奨しています。 ライフサイクル管理ポリシーやストレージアクションタスクを使って、古いバージョンを自動的に削除できます。
ブロブのバージョン管理は、ストレージアカウントやコンテナの誤削除からの回復には役立ちません。 ストレージ アカウントが誤って削除されないようにするには、ストレージ アカウント リソースに対してロックを構成します。 ストレージ アカウントのロックの詳細については、「ストレージ アカウントへのAzure Resource Managerロックを適用するを参照してください。
バージョン ID
各ブロブバージョンには固有のバージョンIDがあります。 バージョンIDの値は、ブロブが更新されたタイムスタンプです。 バージョンIDは作成時に割り当てます。
特定のバージョンのブロックを読み取ったり削除したりするには、バージョンIDを使っています。 バージョンIDを含めなければ、操作は現在のバージョンを対象にします。
Blobを作成または修正するために書き込み操作を行うと、Azure Storageはレスポンスにx-ms-version-idヘッダーを返します。 このヘッダーには、書き込み操作で作成された現在のバージョンのバージョンIDが含まれています。
バージョンIDはバージョンの寿命中ずっと同じままです。
書き込み操作でのバージョン管理
ブロブのバージョン設定を有効にすると、ブロブへの書き込み操作ごとに新しいバージョンが作成されます。 書き込み操作には Put Blob、Put Block List、Copy Blob、および Set Blob Metadata が含まれます。
書き込み操作で新しいブロブが作成されると、その結果生まれたブロブは現在のバージョンのブロブとなります。 書き込み操作が既存のブロブを修正すると、現在のバージョンは以前のバージョンとなり、新しい現在のバージョンが更新されたブロブをキャプチャします。
次の図は、書き込み操作が BLOB のバージョンにどのように影響するかを示しています。 簡単のため、この記事の図ではバージョンIDを単純な整数値として表示しています。 実際には、バージョン ID はタイムスタンプです。 現在のバージョンは青色で示され、以前のバージョンは灰色で示されます。
注
ストレージ アカウントでバージョン管理が有効になる前に作成した Blob にはバージョン ID がありません。 そのブロブを修正すると、その修正されたブロブが新しい現在のバージョンになり、更新前の状態は前のバージョンになります。 現在のバージョンには作成時間を示すバージョンIDが割り当てられています。
ストレージアカウントでブロブのバージョン管理を有効にすると、ブロックブロブに対するすべての書き込み操作は新しいバージョンの作成を引き起こしますが、 Put Block 操作は例外です。
ページ BLOB と追加 BLOB の場合は、書き込み操作のサブセットによってのみ、バージョンの作成がトリガーされます。 記録される操作には次のようなものがあります。
以下の操作は新しいバージョンの作成をトリガーしません:
- Put Page (ページ BLOB)
- Append Block (追加 BLOB)
これらの操作による変更を記録するには、手動スナップショットを作成してください。 詳細は Blobスナップショットをご覧ください。
すべてのバージョンのブロブは同じブロブタイプでなければなりません。 BLOB に以前のバージョンがある場合、BLOB とそのすべてのバージョンを最初に削除しない限り、ある種類の BLOB を別の種類で上書きすることはできません。
削除操作でのバージョン管理
バージョンIDを指定せずに Delete Blob 操作を行うと、現在のバージョンは以前のバージョンになり、現在のバージョンは存在しません。 この操作では、BLOB の既存の旧バージョンがすべて保持されます。
次の図は、バージョン管理された BLOB に対する削除操作の影響を示しています。
特定のバージョンの BLOB を削除するには、削除操作に対してそのバージョンの ID を指定します。 ストレージアカウントのBlobソフト削除も有効にすると、ソフト削除の保持期間が経過するまでシステムはバージョンを保持します。
新しいデータを BLOB に書き込むと、新しい現在のバージョンの BLOB が作成されます。 この操作は既存のバージョンには影響しません。以下の図に示されています。
アクセス階層
Set Blob Tier 操作を呼び出すことにより、現在のバージョンを含む、任意のバージョンのブロック BLOB を別の BLOB のアクセス層に移動することができます。 古いバージョンのブロブをクールやアーカイブ層に移すことで、容量の低価格を享受できます。 詳細については、BLOB データのホット、クール、コールド、アーカイブ アクセス層に関するページを参照してください。
ブロックブロブを適切な階層に移動するプロセスを自動化するには、 ライフサイクル管理 ポリシーを作成し、 ストレージアクション タスクを作成するか、 スマートティアを有効にしてください。
BLOB のバージョン管理を有効または無効にする
ブロブのバージョン管理の有効化または無効化の手順については、「Enable and manage blob versioning」をご覧ください。
BLOB のバージョン管理を無効にしても、既存の BLOB、バージョン、スナップショットは削除されません。 ブロブバージョン管理をオフにすると、新しいバージョンを作成できません。
バージョン管理を無効にした後、現在のバージョンを変更するとバージョンではないブロブが生成されます。 BLOB に対する以降のすべての更新では、前の状態を保存せずにデータが上書きされます。 既存のすべてのバージョンは、以前のバージョンとして保持されます。
バージョン設定が無効になった後は、バージョンIDを使ってバージョンを読み取ったり削除したりできます。 また、バージョン管理が無効になった後に、BLOB のバージョンを一覧表示することもできます。
オブジェクト レプリケーションは、BLOB バージョン管理に依存します。 BLOB バージョン管理を無効にするには、その前にアカウントのオブジェクト レプリケーション ポリシーを削除する必要があります。 オブジェクト レプリケーションの詳細については、「ブロック BLOB のオブジェクト レプリケーション」を参照してください。
次の図は、バージョン管理が無効になった後に BLOB を変更すると、バージョン管理されない BLOB がどのように作成されるかを示しています。 BLOB に関連付けられている既存のすべてのバージョンが保持されます。
機能のサポート
この機能のサポートは、Data Lake Storage Gen2、ネットワーク ファイル システム (NFS) 3.0 プロトコル、または SSH ファイル転送プロトコル (SFTP) を有効にすることによって影響を受ける可能性があります。 これらの機能のいずれかを有効にした場合は、Azure Storage アカウントのBlob Storage機能のサポートを参照して、この機能のサポートを評価してください。
BLOB のバージョン管理は、汎用 v2、Premium ブロック BLOB、および従来の BLOB ストレージ アカウントで使用できます。 Azure Data Lake Storageで使用できるように階層型名前空間が有効になっているストレージ アカウントは、現在サポートされていません。
バージョン 2019-10-10 以降の Azure Storage REST API では、BLOB のバージョン管理がサポートされています。
Data Lake Storage APIを使ってアップロードしたブロブにはバージョン管理がサポートされていません。
blob のバージョンに対する操作を承認する
Blobバージョンへのアクセスを許可するには、以下のいずれかの方法があります:
- Azure role-based access control(Azure RBAC)を使って、Microsoft Entra security principalに権限を付与します。 Microsoftでは、優れたセキュリティと使いやすさのためにMicrosoft Entra IDを使用することをお勧めします。 BLOB 操作でのMicrosoft Entra IDの使用の詳細については、「
Azure Storage を参照してください。 - 共有アクセス署名(SAS)を使って、Blobバージョンへのアクセスを委任します。 特定のバージョンに対する操作用の SAS トークンを作成するには、BLOB バージョンを表す署名付きリソースの種類
bvのバージョン ID を指定します。 Shared Access Signature の詳細については、「 Shared Access Signature (SAS) を使用してAzure Storage リソースへの制限付きアクセスを許可する」を参照してください。 - アカウント アクセス キーを使用して、Shared Key により BLOB バージョンに対する操作を認証します。 詳細については、共有キーによる承認に関するページを参照してください。
BLOB のバージョン管理は、誤削除や悪意のある削除からデータを保護するように設計されています。 保護を強化するために、BLOB バージョンを削除するには特殊なアクセス許可が必要です。 以下のセクションでは、BLOB バージョンを削除するために必要なアクセス許可について説明します。
AzureのRBACアクションでBlobバージョンを削除する
次の表は、Azure RBAC アクションが blob または blob バージョンの削除をサポートするかどうかを示しています。
| 説明 | Blob service の操作 | Azure RBAC データ アクションが必要です | Azure組み込みロールのサポート |
|---|---|---|---|
| 現在のバージョンの削除 | ブロブを削除 | Microsoft/Storage/storageAccounts/blobServices/containers/blobs/delete | ストレージ BLOB データ共同作成者 |
| 以前のバージョンの削除 | ブロブを削除 | Microsoft/Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action | ストレージ BLOB データ所有者 |
Shared Access Signature (SAS) パラメーター
BLOB バージョンの署名済みリソースは、bv です。 詳細については、「サービス SAS を作成する」または「ユーザー委任 SAS の作成」を参照してください。
次の表には、BLOB バージョンを削除するために SAS に必要な権限が示されています。
| 権限 | URI の略記 | 許可される操作 |
|---|---|---|
| 削除 | x | BLOBバージョンを削除する。 |
既存の作業負荷に関する考慮事項
ブロブを削除しても空きスペースは解放されません。 バージョン管理を有効にすると、ブロブを削除してもデータは消えません。 現在のバージョンは以前のバージョンとなり、継続して料金が発生し続けます。 ストレージを回収するために削除操作に依存するワークロードは、明示的にそれらのバージョンを削除するまで料金が発生し続けます。
オーバーライトが多いワークロードはバージョンを蓄積することがあります。 バージョンは明示的に削除するまで残り続けます。 この永続性により、適切に管理しないとバージョンが蓄積される可能性があります。 コスト削減のために、バージョン間でブロックレベルで課金されるように変更を行い、バージョンごとのコストを最小限に抑えましょう。
機能間の相互作用
ソフト削除
BLOB のバージョン管理と BLOB の論理的な削除は、ストレージ アカウントに推奨されるデータ保護構成の一部です。 Microsoftのデータ保護に関する推奨事項の詳細については、「データ保護の概要」を参照してください。
BLOB の上書き
ストレージアカウントでBlobのバージョン設定とBlobソフト削除の両方を有効にすると、Blobを上書きすると自動的に書き込み前のBlobの状態を反映した新しい以前のバージョンが作成されます。 新しいバージョンはソフト削除ではなく、明示的に削除されるまで残ります。 ソフト削除されたスナップショットは作成されません。
Blob またはバージョンの削除
ストレージアカウントでバージョン管理とソフト削除の両方を有効にすると、ブロブを削除すると現在のバージョンが以前のバージョンになります。 この操作は新しいバージョンやソフト削除されたスナップショットを作成しません。 ソフト削除の保持期間は、削除済みのブロブには適用されません。
ソフト削除はブロブのバージョンを削除する際のさらなる保護を提供します。 ブロブの以前のバージョンを削除すると、そのバージョンはソフト削除されます。 ソフト削除されたバージョンは、ソフト削除の保持期間が経過するまで保持され、その後、永久に削除されます。
以前のバージョンの BLOB を削除するには、Delete Blob 操作を呼び出し、バージョン ID を指定します。
ソフト削除されたバージョンの復元
ソフト削除保持期間中にソフト削除されたバージョンを復元するために、 Undelete Blob 操作を使って復元してください。 Undelete Blob 操作では常に、BLOB の論理的に削除されたすべてのバージョンが復元されます。 ソフト削除されたバージョンを1つだけ復元することはできません。
Undelete Blob 操作を使用して論理的に削除されたバージョンを復元しても、どのバージョンも現在のバージョンに昇格されません。 現在のバージョンを復元するには、まず論理的に削除されたすべてのバージョンを復元してから、Copy Blob 操作を使用して以前のバージョンを新しい現在のバージョンにコピーします。
ソフト削除保持期間が経過すると、システムはソフト削除されたブロブバージョンを永久に削除します。
BLOB のスナップショット
ブロブスナップショットとは、特定の時点で取得されたブロブの読み取り専用コピーのことです。 BlobスナップショットとBlobバージョンは似ていますが、スナップショットはあなたやアプリケーションが手動で作成し、BlobバージョンはストレージアカウントでBlobのバージョン設定を有効にすると書き込み・削除操作で自動的に作成されます。
重要
ブロブのバージョン管理を有効にした後、アプリケーションを更新してブロックブロブのスナップショットを取るのをやめてください。 ストレージ アカウントでバージョン管理を有効にすると、バージョンによってすべてのブロック BLOB の更新や削除がキャプチャされ、保持されます。 スナップショットを取っても、Blob のバージョン管理が有効になっている場合、ブロック BLOB データに追加の保護は提供されず、コストやアプリケーションの複雑さが増す可能性があります。
バージョン管理が有効になっている場合に BLOB のスナップショットを作成する
お勧めしませんが、バージョン管理もされる BLOB のスナップショットを作成することができます。 バージョン管理を有効にするときに、BLOB のスナップショットの作成を停止するようにアプリケーションを更新できない場合、アプリケーションではスナップショットとバージョンの両方をサポートできます。
バージョン管理されたブロブのスナップショットを取ると、スナップショットと同時に新しいバージョンを作成します。 また、スナップショットを取る際に新しい現在のバージョンも作成します。
次の図は、バージョニングされた BLOB のスナップショットを作成するときに発生する出来事を示しています。 この図では、バージョン ID が 2 および 3 の BLOB バージョンとスナップショットに同一のデータが含まれています。
既知の制限
階層型名前空間 (Azure Data Lake Storage) アカウントでは、また、Data Lake Storage API を使ってアップロードした blob ではサポートされていません。
コンテナやアカウントの削除を防ぐことはできません。 バージョン管理はブロブレベルでしか機能しません。 コンテナを削除すると、すべてのブロブとそのバージョンが削除されます。 その削除から復元するにはコンテナのソフト削除が必要です。 アカウント削除を防ぐにはリソースロックが必要です。
バージョンは不変です。 既存のバージョンの内容やメタデータを変更することはできません。
すべてのバージョンのブロブは同じブロブタイプでなければなりません。 以前のバージョンがある状態で別のブロブタイプで上書きすることは、先にブロブとそのすべてのバージョンを削除しない限りできません。
すべての書き込みがバージョンを作成するわけではありません。 除外事項を説明しているこの記事の前の方の情報を参照してください。 これらの状態を記録するには、手動スナップショットを使いましょう。
アカウントにオブジェクトレプリケーションポリシーが存在する限り、バージョン管理を無効にできません。 まずすべてのオブジェクト複製ポリシーを削除してください。
Undelete Blobブロブのソフト削除されたすべてのバージョンを復元しますが、単一のものではありません。 1 つのバージョンだけを選択的に削除を元に戻すことはできません。 削除解除でバージョンが現行版になることは決してありません。推奨上限は1 blobあたり1,000バージョン。 それを超えるとブロブリストの性能が低下します。
価格と課金
ブロブのバージョン管理を有効にすると、追加のデータストレージ料金が発生する可能性があります。 アプリケーションを設計する際は、これらの費用がどのように積み重なるかを考慮し、コストを抑えましょう。
ブロブのバージョン、例えばブロブスナップショットに対しては、アクティブデータと同じレートで請求されます。 バージョンの請求方法は、ブロブの現在バージョンまたは過去のバージョン(またはスナップショット)のティアを明示的に設定しているかによって変わります。 BLOB 層の詳細については、BLOB データのホット、クール、コールド、アーカイブ アクセス層に関するページを参照してください。
もし Blob やバージョンの階層を変更しなければ、その Blob、そのバージョン、および関連するスナップショット全体で一意のデータ ブロックに対して課金されます。 詳細については、「BLOB 層が明示的に設定されていない場合の課金」をご覧ください。
ブロブまたはバージョンの階層を変更すると、ブロブとバージョンが同じ階層に戻るかどうかに関わらず、オブジェクト全体に対して請求されます。 詳細については、「BLOB 層が明示的に設定されている場合の課金」を参照してください。
注
頻繁に上書きするデータのバージョン管理を有効にすると、ストレージ容量料金が増加し、リスティング操作中の遅延が発生する可能性があります。 これらの懸念に対処するために、頻繁に上書きされるデータをバージョン設定を無効にした別のストレージアカウントに保存してください。
頻繁にバックアップされるストレージアカウントでバージョンを有効にすると、クールアクセスやコールドアクセス層に保存された際にデータ取得料金が発生する可能性があります。
BLOB のスナップショットの課金の詳細については、「BLOB のスナップショット」を参照してください。
スマートティアを使うストレージアカウントでは、バージョンとスナップショットに対してフルコンテンツの長さで料金を支払います。 詳細については、「 スマート層を使用してコストを最適化する」を参照してください。
BLOB 層を明示的に設定しない場合の課金
もしどのバージョンのBLOB 層も明示的に設定していなければ、すべてのバージョンにわたるユニークなブロックやページ、そして持つ可能性のあるスナップショットに対して請求されます。 Blobのバージョン間で共有されるデータについては、請求されるのは一度だけです。 ブロブを更新すると、新しい現在のバージョンのデータが以前のバージョンに保存されたデータと異なるため、ブロックやページごとに固有のデータ分が請求されます。
ブロックブロブ内でブロックを置き換えると、そのブロックに対しては一意のブロックとして請求されます。 このルールは、ブロックが前のバージョンと同じブロックIDとデータを持っていても適用されます。 再度ブロックをコミットすると、前のバージョンの対応ブロックとの差異が生じ、そのデータ分の料金が請求されます。 同じルールは、同じデータで更新したページブロブのページにも適用されます。
ブロブストレージには、2つのブロックが同一のデータを持っているかどうかを判別する方法はありません。 アップロードしてコミットした各ブロックは、同じデータや同じブロックIDを持っていても一意として扱われます。 ユニークブロックに対して請求されるため、バージョン管理が有効でブロブを更新すると、追加のユニークブロックや追加料金が発生することを覚えておいてください。
ブロブのバージョン設定を有効にすると、ブロックブロブに対して更新操作を呼び出して、できるだけ少ないブロック数を更新するようにしてください。 ブロックの詳細な制御を許可する書き込み操作は、Put Block と Put Block List です。 Put Block は変更をステージングしますが、実際の修正やバージョン作成は Put Block List 操作で行われます。 一方、 Put Blob 操作はブロブの全内容を置き換えるため、追加のチャージが発生する可能性があります。
以下のシナリオは、ブロックのブロブおよびそのバージョンに対して、ブロブの階層を明示的に設定しない場合にチャージがどのように蓄積されるかを示しています。
シナリオ 1
シナリオ 1 では、BLOB に前のバージョンがあります。 ブロブはバージョン作成以降更新されていないため、料金はユニークなブロック1、2、3にのみ発生します。
シナリオ 2
シナリオ2では、ブロブ内の1つのブロック（図のブロック3）が更新されます。 更新されたブロックに同じデータと同じ ID が含まれている場合でも、以前のバージョンのブロック 3 と同じではありません。 このため、4 ブロック分の料金がアカウントに課金されます。
シナリオ 3
シナリオ3では、ブロブは更新されていますが、バージョンは更新されていません。 現在のblobではブロック3がブロック4に置き換えられていますが、以前のバージョンは依然としてブロック3を反映しています。 このため、4 ブロック分の料金がアカウントに課金されます。
シナリオ 4
シナリオ4では、現在のバージョンが完全に更新され、元のブロックは一切含まれていません。 その結果、アカウントは8つのユニークブロックすべてに対して請求されます。現在のバージョンでは4つ、前の2つのバージョンを合わせて4つです。 このシナリオは、 Put Blob 操作を使ってブロブに書き込みを行う場合に起こり得ます。なぜなら、ブロブの内容全体を置き換えるからです。
ブロブティアを明示的に設定したときの請求
ブロブ、バージョン、スナップショットのブロブ層を明示的に設定した場合、元の階層のオブジェクトとブロックを共有しているかどうかに関わらず、新しい階層のオブジェクトの全コンテンツ長さを支払うことになります。 また、オリジナルティアの最古バージョンの全コンテンツ分の料金も支払うことになります。 元のティアに残る他のバージョンやスナップショットについては、 ブロブティアが明示的に設定されていない場合の請求で説明されているように、共有するユニークなブロックに対して料金を支払います。
新しい層への BLOB の移動
以下の表は、ブロブやバージョンを新しいティアに移動した際の請求動作を説明しています。
| ブロブの階層を設定すると... | その後、請求されるのは... |
|---|---|
| 現行または過去のバージョンに明示的に設定 | そのバージョンの完全なコンテンツの長さ。 明示的なセット層を持たないバージョンは、一意のブロックに対してだけ請求されます。1 |
| アーカイブに設定 | すべてのバージョンとスナップショットの全コンテンツ長。1 |
1他に、元のティアから移動していない以前のバージョンまたはスナップショットがある場合、それらのバージョンまたはスナップショットには、BLOB ティアが明示的に設定されていない場合の課金で説明されているように、それらに含まれる一意のブロック数に基づいて課金されます。
以下の図は、バージョン管理されたブロブを別のティアに移動した際のオブジェクトの請求方法を示しています。
Blobやバージョン、スナップショットの階層設定を明示的に元に戻すことはできません。 ブロブを新しいティアに移動させてから元のティアに戻すと、元のティアの他のオブジェクトとブロックを共有していても、そのオブジェクトの全コンテンツ長分の料金を支払うことになります。
BLOB、バージョン、またはスナップショットの層を明示的に設定する操作には、次のものがあります。
- BLOB 層の設定
- Put Blob 層を指定する
- 層を指定した Put Block List
- 層を指定してCopy Blobする
ソフト削除が有効になっている場合の BLOB の削除
Blobソフト削除を有効にすると、すべてのソフト削除されたエンティティに対してライブデータと同じ料金で支払います。 明確にティアを設定した現在のバージョンを削除または上書きすると、ソフト削除されたブロブの過去バージョンについて、コンテンツの全長分の料金を支払うことになります。 Blob のバージョン管理とソフト削除がどのように連携して機能するかの詳細については、機能間の相互作用をご覧ください。
監視とトラブルシューティング
私のLCMポリシーでは、期待どおりのタイミングでバージョンが削除されません: バージョンの経過期間は、以前のバージョンになった時期ではなく、元のデータを書き込んだ時期に基づいています。 カウントはブロブの作成時に開始され、バージョン履歴に追加された上書き時点からではありません。 その結果、上書きされる前に長期間現行状態だったブロブは、上書きされた時点で、すでに
daysAfterCreationGreaterThan閾値を超えている前のバージョンを生成し、そのためほぼ即座に削除されることがあります。 逆に、最近作成されたブロブのバージョンは予想以上に長く持続することもあります。 確認のために、上書き時間と一致するのではなく、バージョンの実際の作成タイムスタンプを確認してください。 バージョンが非現行になった時期に基づいて保持を決めたい場合や、ライフサイクル管理の日単位の閾値を超えた細かな制御を望む場合は、代わりにAzure Storage Actionsの使用を検討してください。 詳細は 「ストレージアクション」をご覧ください。バージョンを無効にした後も請求額が高いままです: 既存のバージョンは手動で削除するまで残ります。
バージョン管理を無効にできません。 オブジェクトのレプリケーションはアカウントで設定されているかもしれません。 まずすべてのオブジェクト複製ポリシーを削除し、その後バージョン管理を無効にしてください。 あるいは、バージョン管理を無効化できないコンテナまたはアカウントに、不変性 (WORM) ポリシーが存在する場合もあります。