BLOB のスナップショット

  • [アーティクル]

スナップショットは、ある時点で作成された読み取り専用の BLOB です。

Note

BLOB バージョン管理により、BLOB の以前のバージョンを維持するための優れた方法が提供されます。 詳細については、「BLOB のバージョン管理」を参照してください。

BLOB スナップショットについて

重要

アカウントのスナップショットで階層型名前空間機能を有効にしているものは現在、プレビュー段階です。 ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用される法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。

プレビューに登録するには、こちらのフォームを参照してください。

スナップショットが作成された日時を示す DateTime 値が BLOB の URI に追加される点を除き、BLOB のスナップショットはベース BLOB とまったく同じです。 たとえば、ページ BLOB の URI が http://storagesample.core.blob.windows.net/mydrives/myvhd の場合、スナップショットの URI は http://storagesample.core.blob.windows.net/mydrives/myvhd?snapshot=2011-03-09T01:42:34.9360000Z のようになります。

Note

すべてのスナップショットがベース BLOB の URI を共有します。 ベース BLOB とスナップショットの唯一の違いは、追加される DateTime 値です。

BLOB に対するスナップショットの数に制限はありません。 スナップショットは、個別に、またはベース BLOB の Delete Blob 操作の一部として明示的に削除されるまで保持されます。 ベース BLOB に関連付けられたスナップショットを列挙して、現在のスナップショットを追跡できます。

BLOB のスナップショットを作成すると、BLOB のシステム プロパティが同じ値でスナップショットにコピーされます。 また、スナップショットの作成時に別のメタデータを指定しない限り、ベース BLOB のメタデータもスナップショットにコピーされます。 作成したスナップショットの読み取り、コピー、削除はできますが、変更はできません。

ベース BLOB に関連付けられているリースはスナップショットに影響しません。 スナップショットでリースを取得することはできません。

BLOB のスナップショットは、ホットまたはクール層に作成できます。 アーカイブ層の BLOB のスナップショットはサポートされていません。

VHD ファイルは、VM ディスクの現時点の情報と状態の格納に使用します。 ディスクを VM 内から切断するか、VM をシャットダウンしてから、その VHD ファイルのスナップショットを撮ることができます。 このスナップショットを後に使用して、その時点での VHD ファイルを取得して VM を再作成することができます。

価格と課金

スナップショット (BLOB の読み取り専用コピー) を作成すると、別途データ ストレージ料金がアカウントに課金される場合があります。 不要なコストを抑えるためにも、アプリケーションを設計する際は、この料金が発生するしくみを理解しておくことが重要です。

BLOB のバージョンと同様に、BLOB のスナップショットは、アクティブなデータと同じレートで課金されます。 スナップショットの課金方法は、ベース BLOB またはそのいずれかのスナップショット (バージョン) のどちらに対して層を明示的に設定したかによって異なります。 BLOB 層の詳細については、「BLOB データのアクセス層」を参照してください。

BLOB またはスナップショットの層を変更していない場合は、その BLOB、そのスナップショット、およびそれが持つ可能性があるすべてのバージョンにわたるデータの一意のブロックに対して課金されます。 詳細については、「BLOB 層が明示的に設定されていない場合の課金」を参照してください。

BLOB またはスナップショットの層を変更した場合は、BLOB とスナップショットが最終的にもう一度同じ層になるかどうかに関係なく、オブジェクト全体に対して課金されます。 詳細については、「BLOB 層が明示的に設定されている場合の課金」を参照してください。

BLOB のバージョンの課金の詳細については、「BLOB のバージョン管理」を参照してください。

スナップショット管理によりコストを最小限に抑える

不要な料金を回避するために、スナップショットを慎重に管理することをお勧めします。 次のベスト プラクティスに従えば、スナップショットの記憶域から発生するコストを最小限に抑えられます。

  • まったく同じデータで更新する場合も含め、BLOB を更新するときは必ずその BLOB に関連付けられているスナップショットを削除してから作成し直すようにします (アプリケーションの設計上、スナップショットを維持しなければならない場合を除く)。 BLOB のスナップショットを削除してから作成し直すと、BLOB とスナップショットの分化を確実に防ぐことができます。
  • BLOB のスナップショットを維持する場合は、BLOB を更新するときに BLOB 全体を上書きするメソッドを呼び出さないでください。 代わりに、コストを抑えるために、可能な限り少ない数のブロックを更新してください。

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

ベース BLOB またはそのいずれかのスナップショットに対して BLOB 層を明示的に設定していない場合は、BLOB、そのスナップショット、およびそれが持つ可能性があるすべてのバージョンにわたる一意のブロックまたはページに対して課金されます。 BLOB とそのスナップショット間で共有されるデータは、1 回だけ課金されます。 BLOB が更新されると、ベース BLOB 内のデータはそのスナップショットに格納されているデータから分岐し、一意のデータはブロックまたはページごとに課金されます。

ブロック BLOB 内のブロックを置き換えた場合、そのブロックは後で一意のブロックとして課金されます。 そのブロックに割り当てられているブロック ID とデータが、スナップショット側と同じであっても変わりません。 ブロックは、もう一度コミットされると、スナップショット内の対応するブロックから分岐し、そのデータに対する料金が発生します。 これは、まったく同じデータでページ BLOB 内のページを更新した場合にも当てはまります。

BLOB ストレージには、2 つのブロックに同一のデータが含まれているかどうかを判断する手段はありません。 アップロードされてコミットされたブロックは、同じデータや同じブロック ID がある場合でも、それぞれが一意のものとして扱われます。 料金は一意のブロックに対して発生するため、その BLOB にスナップショットまたはバージョンがある場合に BLOB を更新すると、一意のブロックが増え、追加料金が発生することを考慮することが重要です。

BLOB にスナップショットがある場合は、ブロック BLOB に対して更新操作を呼び出し、更新されるブロックの数をできる限り少なくします。 ブロックの詳細な制御を許可する書き込み操作は、Put Block と Put Block List です。 一方、Put Blob 操作では、BLOB の内容全体が置き換えられるため、追加料金が発生する可能性があります。

次のシナリオでは、BLOB 層が明示的に設定されていないときに、ブロック BLOB とそのスナップショットに対して料金が発生するしくみを示します。

シナリオ 1

シナリオ 1 では、スナップショットが作成されてからベース BLOB は更新されていません。そのため、料金の発生対象は、一意のブロックである 1、2、3 のみです。

Diagram 1 showing billing for unique blocks in base blob and snapshot.

シナリオ 2

シナリオ 2 では、ベース BLOB は更新されていますが、スナップショットは更新されていません。 更新されたのはブロック 3 です。格納されているデータと ID が同じでも、スナップショット内のブロック 3 とは異なります。 このため、4 ブロック分の料金がアカウントに課金されます。

Diagram 2 showing billing for unique blocks in base blob and snapshot.

シナリオ 3

シナリオ 3 では、ベース BLOB は更新されていますが、スナップショットは更新されていません。 ベース BLOB のブロック 3 がブロック 4 に置き換わっていますが、スナップショット側はブロック 3 のままです。 このため、4 ブロック分の料金がアカウントに課金されます。

Diagram 3 showing billing for unique blocks in base blob and snapshot.

シナリオ 4

シナリオ 4 では、ベース BLOB が完全に更新されており、元のブロックは 1 つも含まれていません。 このため、8 つある一意のブロックすべてについての料金がアカウントに課金されます。

Diagram 4 showing billing for unique blocks in base blob and snapshot.

ヒント

BLOB 全体を上書きするメソッドを呼び出さずに、個別のブロックを更新してコストを抑えるようにします。

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

BLOB またはスナップショット (またはバージョン) の BLOB 層が明示的に設定されている場合、元の層のオブジェクトとブロックが共有されているかどうかにかかわらず、新しい層におけるオブジェクトのコンテンツの完全な長さに対して課金されます。 また、元の層の最も古いバージョンのコンテンツの完全な長さに対しても課金されます。 元の層に残っているすべてのバージョンまたはスナップショットについては、「BLOB 層が明示的に設定されていない場合の課金」で説明されているように、共有できる一意のブロックに対して課金されます。

新しい層への BLOB の移動

次の表では、BLOB またはスナップショットを新しい層に移動する場合の課金の動作について説明します。

BLOB 層の明示的な設定対象 課金の対象
スナップショットがあるベース BLOB 新しい層のベース BLOB と、元の層の最も古いスナップショット、および他のスナップショットの一意のブロック。1
前のバージョンとスナップショットがあるベース BLOB 新しい層のベース BLOB、元の層の最も古いバージョン、元の層の最も古いスナップショット、および他のバージョンまたはスナップショットの一意のブロック。1
スナップショット 新しい層のスナップショットと、元の層のベース BLOB、および他のスナップショットの一意のブロック。1

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

次の図は、スナップショットを持つ BLOB を別の層に移動した場合のオブジェクトの課金方法を示したものです。

Diagram showing how objects are billed when a blob with snapshots is explicitly tiered.

BLOB、バージョン、またはスナップショットに対する層の明示的な設定を、元に戻すことはできません。 BLOB を新しい層に移動した後、元の層に戻すと、元の層の他のオブジェクトとブロックが共有されている場合でも、オブジェクトのコンテンツの完全な長さに対して課金されます。

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

論理的な削除が有効になっている場合の BLOB の削除

BLOB の論理的な削除が有効になっている場合に、層が明示的に設定されているベース BLOB を削除または上書きすると、論理的に削除された BLOB の以前のすべてのバージョンまたはスナップショットが、コンテンツの完全な長さで課金されます。 BLOB のバージョン管理と論理的な削除の連携のしくみの詳細については、「BLOB のバージョン管理と論理的な削除」を参照してください。

次の表では、バージョン管理が有効か無効かによる、論理的に削除される BLOB の課金動作を説明します。 バージョン管理が有効になっている場合、BLOB を論理的に削除すると、新しいバージョンが作成されます。 バージョン管理が無効になっている場合、BLOB を論理的に削除すると、論理的な削除のスナップショットが作成されます。

ベース BLOB を明示的に層を設定して上書きする場合 課金の対象
BLOB の論理的な削除とバージョン管理の両方が有効になっている場合 層に関係なく、すべての既存バージョンがコンテンツ全体の長さで。
BLOB の論理的な削除は有効になっているが、バージョン管理は無効になっている場合 層に関係なく、すべての既存の論理的な削除のスナップショットがコンテンツ全体の長さで。

機能サポート

Data Lake Storage Gen2、Network File System (NFS) 3.0 プロトコル、または SSH ファイル転送プロトコル (SFTP) を有効にすると、この機能のサポートが影響を受ける場合があります。 これらの機能のいずれかを有効にしている場合は、「Azure Storage アカウントでの Blob Storage 機能のサポート」 を参照して、この機能のサポートを評価してください。

次のステップ