Blob のバージョン管理

Blob Storage のバージョン管理を有効にし、以前のバージョンのオブジェクトを自動的に維持することができます。 Blobのバージョン管理を有効にすると、Blobの古いバージョンにアクセスして、変更や削除されたデータを復元できます。

注意事項

ストレージ アカウントの BLOB のバージョン管理を有効にすると、そのアカウント内の BLOB に対するすべての書き込み操作で新しいバージョンが作成されます。 このため、ブロブのバージョン管理を有効にすると追加コストが発生する可能性があります。 コストを最小限に抑えるには、ライフサイクル管理ポリシーを使用して、古いバージョンを自動的に削除します。 ライフサイクル管理の詳細については、「アクセス層を自動化してコストを最適化するAzure Blob Storageを参照してください。

BLOB のバージョン管理のしくみ

バージョンによって、指定された時点での BLOB の状態がキャプチャされます。 各バージョンはバージョン ID で識別されます。 ストレージ アカウントに対して BLOB のバージョン管理が有効になっている場合、AZURE STORAGEは、BLOB が最初に作成され、その後 BLOB が変更されるたびに、一意の ID を持つ新しいバージョンを自動的に作成します。

バージョン ID によって、現在のバージョンまたは以前のバージョンを識別することができます。 BLOB には、一度に 1 つの現在のバージョンのみを含めることができます。

新しい BLOB を作成すると、1 つのバージョンが存在することになり、そのバージョンが現在のバージョンになります。 既存の BLOB を変更すると、現在のバージョンが以前のバージョンになります。 更新された状態を取り込むために新しいバージョンが作成され、その新しいバージョンが現在のバージョンになります。 ある BLOB を削除すると、その BLOB の現在のバージョンが前のバージョンになり、現在のバージョンは存在しなくなります。 その BLOB の以前のすべてのバージョンが保持されます。

次の図は、書き込み操作でバージョンがどのように作成され、以前のバージョンがどのように現在のバージョンに昇格されるかを示しています。

Blobのバージョン管理が書き込み操作でバージョンを作成・昇格させる様子を示す図。

重要

BLOB ごとに多数のバージョンがあると、BLOB の一覧表示操作の待機時間が長くなる可能性があります。 Microsoftでは、BLOB あたり 1,000 未満のバージョンを維持することをお勧めします。 ライフサイクル管理を使用して、古いバージョンを自動的に削除できます。 ライフサイクル管理の詳細については、「アクセス層を自動化してコストを最適化するAzure Blob Storageを参照してください。

BLOB のバージョンは変更できません。 既存の BLOB バージョンの内容やメタデータを変更することはできません。

BLOB のバージョン管理は、汎用 v2、Premium ブロック BLOB、および従来の BLOB ストレージ アカウントで使用できます。 Azure Data Lake Storageで使用できるように階層型名前空間が有効になっているストレージ アカウントは、現在サポートされていません。

バージョン 2019-10-10 以降の Azure Storage REST API では、BLOB のバージョン管理がサポートされています。

重要

ブロブのバージョン管理は、ストレージアカウントやコンテナの誤削除からの回復には役立ちません。 ストレージ アカウントが誤って削除されないようにするには、ストレージ アカウント リソースに対してロックを構成します。 ストレージ アカウントのロックの詳細については、「ストレージ アカウントへの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 にどのように影響するかを示す図。

注

ストレージアカウントでブロブのバージョン管理を有効にすると、ブロックブロブに対するすべての書き込み操作は新しいバージョンの作成を引き起こしますが、 Put Block 操作は例外です。

ページ BLOB と追加 BLOB の場合は、書き込み操作のサブセットによってのみ、バージョンの作成がトリガーされます。 記録される操作には次のようなものがあります。

次の操作では、新しいバージョンの作成はトリガーされません。 これらの操作から変更をキャプチャするには、手動スナップショットを作成します。

すべてのバージョンのブロブは同じブロブタイプでなければなりません。 BLOB に以前のバージョンがある場合、BLOB とそのすべてのバージョンを最初に削除しない限り、ある種類の BLOB を別の種類で上書きすることはできません。

削除操作でのバージョン管理

バージョン ID を指定せずに Delete Blob 操作を呼び出すと、現在のバージョンが以前のバージョンになり、現在のバージョンは存在しなくなります。 この操作では、BLOB の既存の旧バージョンがすべて保持されます。

次の図は、バージョン管理された BLOB に対する削除操作の影響を示しています。

バージョン管理された BLOB の削除を示す図。

特定のバージョンの BLOB を削除するには、削除操作に対してそのバージョンの ID を指定します。 ストレージアカウントのBlobソフト削除も有効にすると、ソフト削除の保持期間が経過するまでシステムはバージョンを保持します。

新しいデータを BLOB に書き込むと、新しい現在のバージョンの BLOB が作成されます。 この操作は既存のバージョンには影響しません。以下の図に示されています。

削除後のバージョン管理された BLOB の再作成を示す図。

アクセス階層

Set Blob Tier 操作を呼び出すことにより、現在のバージョンを含む、任意のバージョンのブロック BLOB を別の BLOB のアクセス層に移動することができます。 古いバージョンのブロブをクールやアーカイブ層に移すことで、容量の低価格を享受できます。 詳細については、BLOB データのホット、クール、コールド、アーカイブ アクセス層に関するページを参照してください。

ブロックブロブを適切な階層に移動するプロセスを自動化するには、ブロブライフサイクル管理を使います。 ライフサイクル管理の詳細については、「Azure Blobストレージのライフサイクル管理」をご覧ください。

BLOB のバージョン管理を有効または無効にする

BLOB のバージョン管理を有効または無効にする方法については、「BLOB のバージョン管理を有効にして管理する」をご覧ください。

BLOB のバージョン管理を無効にしても、既存の BLOB、バージョン、スナップショットは削除されません。 BLOB のバージョン管理を無効にした場合、既存のすべてのバージョンはストレージ アカウントで引き続きアクセス可能です。 その後、新しいバージョンは作成されません。

バージョン管理を無効にした後は、現在のバージョンを変更すると、バージョンではない BLOB が作成されます。 BLOB に対する以降のすべての更新では、前の状態を保存せずにデータが上書きされます。 既存のすべてのバージョンは、以前のバージョンとして保持されます。

バージョン設定が無効になった後は、バージョンIDを使ってバージョンを読み取ったり削除したりできます。 また、バージョン管理が無効になった後に、BLOB のバージョンを一覧表示することもできます。

オブジェクト レプリケーションは、BLOB バージョン管理に依存します。 BLOB バージョン管理を無効にするには、その前にアカウントのオブジェクト レプリケーション ポリシーを削除する必要があります。 オブジェクト レプリケーションの詳細については、「ブロック BLOB のオブジェクト レプリケーション」を参照してください。

次の図は、バージョン管理が無効になった後に BLOB を変更すると、バージョン管理されない BLOB がどのように作成されるかを示しています。 BLOB に関連付けられている既存のすべてのバージョンが保持されます。

バージョン管理を無効にした後に現在のバージョンを変更すると、バージョンではない BLOB が作成されることを示す図。

Blob のバージョン管理と論理的な削除

BLOB のバージョン管理と BLOB の論理的な削除は、ストレージ アカウントに推奨されるデータ保護構成の一部です。 Microsoftのデータ保護に関する推奨事項の詳細については、「データ保護の概要」を参照してください。

BLOB の上書き

ストレージ アカウントに対して BLOB のバージョン管理と BLOB の論理的な削除の両方が有効になっている場合、BLOB を上書きすると、新しいバージョンが自動的に作成されます。 新しいバージョンは論理的に削除されず、論理的な削除の保持期間が過ぎても削除されません。 ソフト削除されたスナップショットは作成されません。

Blob またはバージョンの削除

ストレージアカウントでバージョン管理とソフト削除を有効にした場合、ブロブを削除すると現在のバージョンが前のバージョンになります。 この操作は新しいバージョンを作成したり、スナップショットをソフト削除したりしません。 ソフト削除の保持期間は、削除済みのブロブには適用されません。

ソフトデリットはブロブ版を削除する際の追加保護を提供します。 ブロブの以前のバージョンを削除すると、そのバージョンはソフト削除されます。 ソフト削除版はソフト削除の保持期間が終了するまで保存され、その後永久に削除されます。

以前のバージョンの BLOB を削除するには、Delete Blob 操作を呼び出し、バージョン ID を指定します。

次の図は、BLOB または BLOB のバージョンを削除した場合の動作を示しています。

論理的な削除が有効になっているバージョンの削除を示す図。

ソフト削除されたバージョンの復元

Undelete Blob 操作を使用すると、ソフト削除されたバージョンをソフト削除の保持期間中に復元できます。 Undelete Blob 操作では常に、BLOB の論理的に削除されたすべてのバージョンが復元されます。 ソフト削除されたバージョンを1つだけ復元することはできません。

Blob の削除取り消し操作を使用してソフト削除されたバージョンを復元しても、どのバージョンも現在のバージョンに昇格されることはありません。 現在のバージョンを復元するには、まず論理的に削除されたすべてのバージョンを復元してから、Copy Blob 操作を使用して以前のバージョンを新しい現在のバージョンにコピーします。

以下の図は、 Undelete Blob 操作を使ってソフト削除されたブロブバージョンを復元する方法と、 Copy Blob 操作を使って現在のバージョンを復元する方法を示しています。

ソフト削除されたバージョンを復元する方法を示す図。

ソフト削除の保持期間が終了すると、ソフト削除されたブロブバージョンは永久に削除されます。

BLOB のバージョン管理と BLOB のスナップショット

ブロブスナップショットとは、特定の時点で取得されたブロブの読み取り専用コピーのことです。 ブロブスナップショットとブロブバージョンは似ていますが、あなたやアプリケーションが手動でスナップショットを作成し、一方でブロブバージョンはストレージアカウントでブロブのバージョン管理を有効にすると、書き込み・削除操作中に自動的に生成されます。

重要

Microsoftでは、BLOB のバージョン管理を有効にした後、ブロック BLOB のスナップショットの作成を停止するようにアプリケーションを更新することをお勧めします。 ストレージアカウントでバージョン管理を有効にすると、バージョンを使ってすべてのブロックブロブの更新と削除が記録・保存されます。 スナップショットを取っても、ブロブのバージョン管理が有効になっている場合、ブロックのブロブデータに追加の保護は提供されず、コストやアプリケーションの複雑さが増す可能性があります。

バージョン管理が有効になっている場合に BLOB のスナップショットを作成する

推奨されませんが、バージョンが設定されているブロブのスナップショットを作成できます。 バージョン管理を有効にするときに、BLOB のスナップショットの作成を停止するようにアプリケーションを更新できない場合、アプリケーションではスナップショットとバージョンの両方をサポートできます。

バージョン管理されたブロブのスナップショットを取得すると、スナップショットを作成するのと同時に新しいバージョンも作成します。 また、スナップショットを取る際に新しい現在のバージョンも作成します。

次の図は、バージョニングされた BLOB のスナップショットを作成するときに発生する出来事を示しています。 この図では、バージョン ID が 2 および 3 の BLOB バージョンとスナップショットに同一のデータが含まれています。

バージョン付きブロブのスナップショットを示す図。

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 のスナップショットと同様に、BLOB のバージョンは、アクティブなデータと同じレートで課金されます。 バージョンの支払い方法は、ブロブ(またはスナップショット)の現在または過去のバージョンのティアを明示的に設定しているかどうかによります。 BLOB 層の詳細については、BLOB データのホット、クール、コールド、アーカイブ アクセス層に関するページを参照してください。

もしブロブやバージョンの階層を変更しなければ、そのブロブ全体にまたがるユニークなデータブロック、バージョン、そしてスナップショットに対して料金を支払うことになります。 詳細については、「BLOB 層が明示的に設定されていない場合の課金」をご覧ください。

ブロブやバージョンのティアを変更すると、ブロブとバージョンが同じティアに戻るかどうかに関わらず、オブジェクト全体の料金を支払うことになります。 詳細については、BLOB 層が明示的に設定されている場合の課金をご覧ください。

注

頻繁に上書きされるデータのバージョン管理を有効にすると、ストレージ容量の負担が増え、リスティング操作中の遅延が増加する可能性があります。 これらの問題を軽減するには、頻繁に上書きされるデータを、バージョン管理が無効になっている別のストレージ アカウントに格納します。

頻繁にバックアップされるストレージ アカウントでバージョンを有効にすると、バージョンがクール アクセス層またはコールド アクセス層に格納されている場合に、データ取得料金が発生する可能性があります。

BLOB のスナップショットの課金の詳細については、「BLOB のスナップショット」を参照してください。

スマートティアを使うストレージアカウントでは、バージョンとスナップショットに対してフルコンテンツの長さで料金を支払います。 詳細については、「 スマート層を使用してコストを最適化する」を参照してください。

ブロブ tier を明示的に設定しない場合の課金

BLOB のどのバージョンにもアクセス層を明示的に設定していない場合は、すべてのバージョンおよびその BLOB が持つスナップショット全体で一意のブロックまたはページに対して課金されます。 共有データの支払いは、Blobバージョン間で一度だけ支払います。 ブロブを更新すると、新しい現在のバージョンのデータが以前のバージョンに保存されたデータと異なり、ブロックやページごとに固有のデータに料金を支払うことになります。

ブロック BLOB 内のブロックを置き換えると、そのブロックは別個のブロックとして課金されます。 このルールは、ブロックが前のバージョンと同じブロックIDおよびデータを持っていても適用されます。 再度ブロックをコミットすると、前のバージョンの対応するものと乖離し、そのデータの代金を支払うことになります。 同じルールは、同じデータで更新したページブロブのページにも適用されます。

ブロブストレージには、2つのブロックが同一のデータを持っているかどうかを判別する方法はありません。 アップロードしてコミットした各ブロックは、同じデータや同じブロックIDを持っていても一意として扱われます。 ユニーク ブロックに対して課金されるため、バージョン管理が有効になっている状態でブロブを更新すると、ユニーク ブロックがさらに増え、追加料金が発生することにご留意ください。

ブロブのバージョン設定を有効にすると、ブロックブロブに対して更新操作を呼び出して、できるだけ少ないブロック数を更新するようにしてください。 ブロックの詳細な制御を許可する書き込み操作は、Put Block と Put Block List です。 一方、 Put Blob 操作はブロブの全内容を置き換えるため、追加のチャージが発生する可能性があります。

以下のシナリオは、ブロックのブロブおよびそのバージョンに対して、ブロブの階層を明示的に設定しない場合にチャージがどのように蓄積されるかを示しています。

シナリオ 1

シナリオ 1 では、BLOB に前のバージョンがあります。 ブロブはバージョン作成以降更新されていないため、料金はユニークなブロック1、2、3にのみ発生します。

図1はbase blobおよび以前のバージョンにおけるユニークなブロックの請求を示しています。

シナリオ 2

シナリオ2では、ブロブ内の1ブロック(図のブロック3)を更新します。 更新されたブロックに同じデータと同じ ID が含まれている場合でも、以前のバージョンのブロック 3 と同じではありません。 その結果、4ブロック分の料金を支払うことになります。

ベースブロブおよび以前のバージョンにおけるユニークなブロックの請求を示す図2。

シナリオ 3

シナリオ3では、ブロブは更新しますが、バージョン自体は更新しません。 現在のブロブでブロック3をブロック4に置き換えますが、以前のバージョンはブロック3を反映しています。 その結果、4ブロック分の料金を支払うことになります。

ベースブロブおよび以前のバージョンにおけるユニークなブロックの請求を示す図3。

シナリオ 4

シナリオ4では、現在のバージョンを完全に更新し、元のブロックは一切含まれていません。 その結果、8つのユニークなブロックすべてに料金を支払うことになります。現在のバージョンでは4つ、前の2つのバージョンでは4つが合計です。 このシナリオは、 Put Blob 操作を使ってブロブに書き込みを行う場合に起こり得ます。なぜなら、ブロブの内容全体を置き換えるからです。

ベースブロブおよび以前のバージョンにおけるユニークなブロックの請求を示す図4。

BLOB 層が明示的に設定されている場合の課金

ブロブ、バージョン、スナップショットのブロブ層を明示的に設定した場合、新しい階層のオブジェクトの全コンテンツ長さを支払うことになります。たとえ元の階層のオブジェクトとブロックを共有していてもです。 また、オリジナルティアの最古バージョンの全コンテンツ分の料金も支払うことになります。 元のティアに残る他のバージョンやスナップショットについては、 ブロブティアが明示的に設定されていない場合の請求で説明されているように、共有するユニークなブロックに対して料金を支払います。

新しい層への BLOB の移動

以下の表は、ブロブやバージョンを新しいティアに移動した際の請求動作を説明しています。

ブロブの階層を設定すると... その後、請求されるのは...
現在または以前のバージョンに明示的に依存する場合 そのバージョンの完全なコンテンツの長さ。 明示的なセット層を持たないバージョンは、一意のブロックに対してだけ請求されます。1
アーカイブする方法 すべてのバージョンとスナップショットの完全なコンテンツの長さ。1.

1他に、元のティアから移動していない以前のバージョンまたはスナップショットがある場合、それらのバージョンまたはスナップショットには、BLOB ティアが明示的に設定されていない場合の課金で説明されているように、それらに含まれる一意のブロック数に基づいて課金されます。

次の図は、バージョン管理された BLOB を別の層に移動した場合のオブジェクトの課金方法を示したものです。

バージョン管理された BLOB が明示的に階層化されたときのオブジェクトの課金方法を示す図。

Blobやバージョン、スナップショットの階層設定を明示的に元に戻すことはできません。 ブロブを新しいティアに移動させてから元のティアに戻すと、元のティアの他のオブジェクトとブロックを共有していても、そのオブジェクトの全コンテンツ長分の料金を支払うことになります。

BLOB、バージョン、またはスナップショットの層を明示的に設定する操作には、次のものがあります。

ソフト削除が有効になっている場合の BLOB の削除

Blobソフト削除を有効にすると、すべてのソフト削除されたエンティティに対してライブデータと同じ料金で支払います。 明確に設定された階層がある現在のバージョンを削除または上書きすると、ソフト削除されたブロブの以前のバージョンに対してフルコンテンツの長さで支払います。 BLOB のバージョン管理と論理的な削除の連携のしくみの詳細については、「BLOB のバージョン管理と論理的な削除」を参照してください。

機能のサポート

この機能のサポートは、Data Lake Storage Gen2、ネットワーク ファイル システム (NFS) 3.0 プロトコル、または SSH ファイル転送プロトコル (SFTP) を有効にすることによって影響を受ける可能性があります。 これらの機能のいずれかを有効にした場合は、Azure Storage アカウントのBlob Storage機能のサポートを参照して、この機能のサポートを評価してください。

Data Lake Storage APIを使ってアップロードしたブロブにはバージョン管理がサポートされていません。

関連項目

  • Last updated on