スナップショットとは、特定の時点で取得されたブロブの読み取り専用コピーのことです。 ブロブスナップショット機能を有効にする必要はありません。 代わりに、 Snapshot Blob 操作を使ってオンデマンドでスナップショットを作成します。 詳細は「Snapshot Blob 操作」を参照してください。 スケジュールや特定の操作の前後にブロブのポイントインタイムコピーをキャプチャするために、カスタムスクリプトを使ってスナップショット作成を自動化できます。
推奨されるデータ保護の構成
ブロブスナップショットは、いくつかのデータ保護機能の一つです。 適切な機能や機能の組み合わせを選ぶことは、あなたの作業負荷や何から保護するかによって異なります。 Microsoftのデータ保護に関する推奨事項については、「データ保護概要」をご覧ください。
スナップショット対バージョン
スナップショットはブロブ版に似ていますが、作成方法や最適な用途が異なります。 スナップショットは手動でアプリケーション主導型です。アプリケーションが必要だと判断した時点で、明示的に特定時点のコピーを作成します。 バージョンの作成は自動的にシステムによって管理されます。Azure Storageは、Blobのバージョン管理を有効にすると、書き込みや削除のたびに新しいバージョンを作成し、アプリケーションロジックは不要です。
偶発的または悪意のある上書きや削除を防ぐための自動的かつ継続的な保護が必要な場合は、バージョン管理を活用しましょう。 すべての変更を逐一記録するのではなく、予定されている更新の前に正常に動作することが確認されたチェックポイントを作成する場合など、意図的に特定時点のコピーを残したいときにスナップショットを使用します。
注
スナップショットを使用してバージョン管理の動作をある程度再現することもできますが、Microsoft は、FNS アカウントで自動的な上書きや削除から保護するために、Blob のバージョン管理を推奨しています。 スナップショットは、すべての変更を記録する保護よりも、意図的なポイントインタイムキャプチャに最適です。 詳細については、 Blobのバージョン管理を参照してください。
スナップショットの仕組み
ブロブのスナップショットはベース ブロブと同一ですが、異なるのは、スナップショットが取得された時刻を示すために、ブロブ URI に DateTime 値が追加される点だけです。 たとえば、ページ 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 のようになります。
BLOB のスナップショットを作成すると、BLOB のシステム プロパティが同じ値でスナップショットにコピーされます。 また、スナップショットの作成時に別のメタデータを指定しない限り、ベース BLOB のメタデータもスナップショットにコピーされます。 作成したスナップショットの読み取り、コピー、削除はできますが、変更はできません。 ベース BLOB に関連付けられているリースはスナップショットに影響しません。 スナップショットでリースを取得することはできません。
BLOB は任意の数のスナップショットを持つことができます。 スナップショットは、単独で、またはベースブロブに対するDelete Blob操作の一部として明示的に削除されるまで保持されます。 ホット、コールド、またはクール階層にある Blob のスナップショットを作成できます。 アーカイブされたブロブのスナップショットを作成することはできません。
重要
1つのブロブに多数のスナップショットを持つことで、ブロブのリスト付け処理の遅延が増加します。 Microsoftは1つのブロブあたり1,000枚未満のスナップショットを維持することを推奨しています。 ライフサイクル管理を使えば、古いスナップショットを自動的に削除できます。 ライフサイクル管理の詳細については、「Azure Blob Storage のアクセス層を自動化してコストを最適化する」をご覧ください。
スナップショットは、Blobのバージョン管理で捉えられないBlobの種類や操作に特に有用です。 Put Page (ページ BLOB) や Append Block (追加 BLOB) などの一部の書き込み操作では、バージョン管理が有効になっていても BLOB バージョンは作成されません。そのため、これらの API を使用する場合、スナップショットは BLOB の特定時点の状態を取得する手段となります。 例えば、VHDファイルはVMディスクの現在の情報とステータスを保存します。 VM内でディスクを切り離すか、VMをシャットダウンしてVHDファイルのスナップショットを取得し、そのスナップショットを使ってその時点でVHDファイルを取得し、VMを再作成することができます。
次の図は、スナップショットがどのように作成されるか、またスナップショットがどのように現在の Blob に昇格されるかを示しています:
スナップショットの管理と復元
スナップショットを作成、一覧表示、削除できます。 また、スナップショットを使ってベースブロブを以前の状態に戻すこともできます。 以下のセクションでは、各操作と対応するツールについて説明します。
スナップショットから BLOB を復元する
スナップショットは変更できないため、ベースブロブを復元するには、その上にスナップショットをコピーします。 コピーBlob操作を呼び出し、コピーソースとしてスナップショットURIを指定します。 このプロセスにより、スナップショットの状態は現在のベースブロブに昇格しつつ、ブロブの既存のスナップショットは保持されます。
スナップショットを一覧表示する
List Blobs 操作を使い、snapshots パラメーターで include 値を指定することで、ベース ブロブに関連付けられたスナップショットを列挙して、現在のスナップショットを追跡できます。 デフォルトでは、blob の一覧取得要求はスナップショットを返しません。
include=snapshots を、ベース BLOB とともに各 BLOB のすべてのスナップショットを返すように設定してください。 詳細については、List Blobs を参照してください。 また、Azure Storageブロブインベントリを使って、インベントリルールの定義でincludeSnapshotsフィールドをtrueに設定することで、アカウント内のブロブのスケジュールレポート(スナップショットを含む)を生成することもできます。 詳細は「 ブロブ・インベントリ」をご覧ください。
スナップショットの削除
スナップショットは明示的に削除しなければなりません。 個々のスナップショットを削除するには、 Delete Blob 操作を呼び出し、スナップショットクエリパラメータでそのスナップショットのDateTime値を指定します。
ベースブロブがアクティブなスナップショットがある間は削除できません。 ベース ブロブとそのすべてのスナップショットをまとめて削除するには、x-ms-delete-snapshots を呼び出し、include ヘッダーを に設定します。 スナップショットだけを削除し、ベースのBlobを保持するにはヘッダーを onlyに設定してください。
ツールでスナップショットを管理する
スナップショットはポータル、Azure CLI、Azure PowerShellを使って管理できます。
- ポータル
- PowerShell
- Azure CLI
Azureポータルを使ってブロブのスナップショットを作成するには、以下の手順に従ってください:
- Azure portal のストレージ アカウントに移動します。
- データストレージの中でコンテナオプションを見つけ、ブロブを収容するコンテナを選択します。
- スナップショットしたいブロブを選択します。
- Blob の 概要 タブで「スナップショットの作成」を選択してください。
- BLOB のスナップショットを表示するには、スナップショット タブを選択します。このタブには、各スナップショットと、それが作成された日時が一覧表示されます。
機能のサポート
この機能はData Lake Storage Gen2アカウントでは有効になっていません。 さらに、Network File System(NFS) 3.0プロトコル、またはSSHファイル転送プロトコル(SFTP)がこの機能のサポートに影響を与える可能性があります。 これらの機能のいずれかを有効にした場合は、Azure StorageアカウントのBlob Storage機能サポートを参照して、この機能のサポートを評価してください。 代替のメカニズムを検討してください。 例としては、ブロブのソフト削除、AzCopy、Vaulted Backupなどがあります。
特徴の相互作用
Versioning
バージョニングを有効にすると、スナップショットは通常ブロックブロブに対して冗長になります。 バージョニングとスナップショットの両方を同時に有効にすると、スナップショットを取るとスナップショットと新しいバージョンの両方が作成されます。 このプロセスは保護を加えることなく、保存されるオブジェクトの数を増やします。 詳細については、「BLOB のバージョン管理」を参照してください。
ソフト削除
ソフトデリットはスナップショットに適用されます。スナップショットを削除するとソフトデリットになります。 保持期間中にUndelete Blobを使うことで復元できます。 さらに、スナップショットの作成方法や請求方法はバージョン管理が有効かどうかによって異なります。 バージョン管理が無効になっている場合、ブロブを上書きすることでソフトデリットスナップショットが作成されます。 バージョン管理を有効にすると、新しいバージョンが作成されます。 ベースブロブにティアを明示的に設定した場合、ソフト削除されたブロブの以前のバージョンまたはスナップショットについては、コンテンツの全長に対して課金されます。 この請求の仕組みの詳細については、「価格設定と請求」セクションをご覧ください。 ソフトデリットの詳細については、 Blob Soft Deleteをご覧ください。
オブジェクト レプリケーション
スナップショットは複製できません。 複製されるのは基本のブロブだけです。 詳細については 、オブジェクト複製を参照してください。
ライフサイクル管理
ライフサイクル管理は、ポリシールール内のスナップショットサブタイプを使ってスナップショットをターゲットにし、削除することができます。 詳細については 、ライフサイクル管理を参照してください。
価格と課金
スナップショット (BLOB の読み取り専用コピー) を作成すると、別途データ ストレージ料金がアカウントに課金される場合があります。 申請書を設計する際は、これらの料金がどのように発生するかを把握し、コストを最小限に抑えましょう。
BLOB のバージョンと同様に、BLOB のスナップショットは、アクティブなデータと同じレートで課金されます。 スナップショットの請求方法は、ベース Blob の階層を明示的に設定したか、またはそのスナップショット (またはバージョン) のいずれかに対して階層を明示的に設定したかどうかによって決まります。 BLOB 層の詳細については、「BLOB データのアクセス層」を参照してください。
ブロブまたはスナップショットの階層を変更しない場合、そのブロブ、そのスナップショット、および存在する可能性のあるすべてのバージョンにまたがる一意のデータ ブロックに対して課金されます。 詳細については、「BLOB 層が明示的に設定されていない場合の課金」を参照してください。
Blob やスナップショットの階層を変更した場合、結果整合性によって Blob とスナップショットが再び同じレベルに戻ったかどうかに関わらず、そのオブジェクト全体に対して課金されます。 詳細については、「BLOB 層が明示的に設定されている場合の課金」を参照してください。
スマート層を利用するストレージ アカウントの場合、バージョンとスナップショットは完全なコンテンツ長で課金されます。 詳細については、「 スマート層を使用してコストを最適化する」を参照してください。
BLOB のバージョンの課金の詳細については、「BLOB のバージョン管理」を参照してください。
スナップショット管理によりコストを最小限に抑える
追加料金を避けるために、スナップショットの管理を慎重に行ってください。 スナップショットの保存コストを最小限に抑えるために、以下のベストプラクティスを実践してください:
- まったく同じデータで更新する場合も含め、BLOB を更新するときは必ずその BLOB に関連付けられているスナップショットを削除してから作成し直すようにします (アプリケーションの設計上、スナップショットを維持しなければならない場合を除く)。 ブロブのスナップショットを削除して再作成することで、ブロブとスナップショットが分岐しないようにします。
- BLOB のスナップショットを維持する場合は、BLOB を更新するときに BLOB 全体を上書きするメソッドを呼び出さないでください。 代わりに、コストを抑えるためにできるだけ少ない数のブロックを更新しましょう。
BLOB 層を明示的に設定しない場合の課金
ベース Blob またはそのスナップショットのいずれかに対して Blob tier を明示的に設定しない場合、Blob、そのスナップショット、および存在する可能性のあるすべてのバージョン全体で一意のブロックまたはページに対して料金を支払うことになります。 ブロブとそのスナップショットが共有するデータに対しては、一度だけ料金が発生します。 ブロブを更新すると、ベースブロブのデータがスナップショットに保存されたデータと異なり、ブロックやページごとにユニークなデータに料金を支払います。
ブロック BLOB 内でブロックを置き換えると、そのブロックは後でユニーク ブロックとして課金されます。 このルールは、ブロックがスナップショット内のものと同じブロックIDおよび同じデータを持っていても適用されます。 再度ブロックをコミットすると、スナップショット内の対応するブロックと乖離し、そのデータ分の料金が発生します。 同じルールは、同じデータで更新されたページブロブのページにも適用されます。
ブロブストレージには、2つのブロックが同一のデータを持っているかどうかを判別する方法はありません。 アップロードしてコミットした各ブロックは、同じデータや同じブロックIDを持っていても一意として扱われます。 ユニーク ブロックごとに課金されるため、スナップショットやバージョンを持つブロブを更新すると、追加のユニーク ブロックや追加料金が発生することを覚えておいてください。
BLOB にスナップショットがある場合は、ブロック BLOB に対して更新操作を呼び出し、更新されるブロックの数をできる限り少なくします。 ブロックの詳細な制御を許可する書き込み操作は、Put Block と Put Block List です。 一方、 Put Blob 操作はブロブの全内容を置き換えるため、追加のチャージが発生する可能性があります。
以下のシナリオは、ブロック ブロブとそのスナップショットに対して、ブロブ層を明示的に設定しない場合に料金がどのように発生するかを示しています。
シナリオ 1
シナリオ 1 では、スナップショットが作成されてからベース BLOB は更新されていません。そのため、料金の発生対象は、一意のブロックである 1、2、3 のみです。
シナリオ 2
シナリオ 2 では、ベース BLOB は更新されていますが、スナップショットは更新されていません。 更新されたのはブロック 3 です。格納されているデータと ID が同じでも、スナップショット内のブロック 3 とは異なります。 このため、4 ブロック分の料金がアカウントに課金されます。
シナリオ 3
シナリオ 3 では、ベース BLOB は更新されていますが、スナップショットは更新されていません。 ベース BLOB のブロック 3 がブロック 4 に置き換わっていますが、スナップショット側はブロック 3 のままです。 このため、4 ブロック分の料金がアカウントに課金されます。
シナリオ 4
シナリオ 4 では、ベース BLOB が完全に更新されており、元のブロックは 1 つも含まれていません。 このため、8 つある一意のブロックすべてについての料金がアカウントに課金されます。
ヒント
コストを抑えるために、ブロブ全体を上書きするメソッドを呼び出すのは避けましょう。 代わりに、個々のブロックを更新してください。
ブロブティアを明示的に設定したときの請求
ブロブ、スナップショット、またはバージョンに対してブロブ階層を明示的に設定した場合、元の階層のオブジェクトとブロックを共有しているかどうかに関わらず、新しい階層のオブジェクトの全コンテンツ長さの料金を支払います。 また、オリジナルティアの最古バージョンの全コンテンツ分の料金も支払うことになります。 BLOB ティアが明示的に設定されていない場合の課金で説明されているように、元のティアに残るバージョンまたはスナップショット内のユニーク ブロックに対して支払う必要があります。
新しい層への BLOB の移動
以下の表は、ブロブやスナップショットを新しいティアに移動した際の請求動作を説明しています。
| ブロブティアを明示的に設定した場合... | 課金の対象 |
|---|---|
| スナップショットがあるベース BLOB | 新しい層のベース BLOB と、元の層の最も古いスナップショット、および他のスナップショットの一意のブロック。1 |
| 前のバージョンとスナップショットがあるベース BLOB | 新しい階層のベースブロブ、元の階層の最も古いバージョン、元の階層の最も古いスナップショット、そして他のバージョンやスナップショットのユニークなブロックです。1 |
| スナップショット | 新しい層のスナップショットと、元の層のベース BLOB、および他のスナップショットの一意のブロック。1 |
1他の以前のバージョンやスナップショットを元のティアから移動しなかった場合は、Blob ティアが明示的に設定されていない場合の課金 で説明されているように、それらに含まれるユニーク ブロック数に基づいて課金されます。
以下の図は、スナップショット付きのブロブを別の階層に移動した際のオブジェクトの請求方法を示しています。
Blobやバージョン、スナップショットの階層設定を明示的に元に戻すことはできません。 ブロブを新しいティアに移動させてから元のティアに戻すと、元のティアの他のオブジェクトとブロックを共有していても、そのオブジェクトの全コンテンツ長分の料金を支払うことになります。
BLOB、バージョン、またはスナップショットの層を明示的に設定する操作には、次のものがあります。
層を指定した Put Blob
Put Block List に層を指定する
層を指定した Copy Blob
ソフト削除が有効になっている場合の BLOB の削除
ブロブのソフト削除が有効になっている場合、明示的に階層を設定したベース ブロブを削除または上書きすると、ソフト削除されたブロブの以前のバージョンまたはスナップショットのコンテンツ全体の長さに対する料金を支払います。 Blob のバージョン管理とソフト削除がどのように連携して機能するかの詳細については、機能間の相互作用をご覧ください。
次の表では、バージョン管理が有効か無効かによる、論理的に削除される BLOB の課金動作を説明します。 バージョン管理が有効になっている場合、BLOB を論理的に削除すると、新しいバージョンが作成されます。 バージョン管理が無効になっている場合、BLOB を論理的に削除すると、論理的な削除のスナップショットが作成されます。
| ベース BLOB を明示的に層を設定して上書きする場合 | 課金の対象 |
|---|---|
| BLOB の論理的な削除とバージョン管理の両方が有効になっている場合 | 層に関係なく、すべての現存するバージョンが完全なコンテンツの長さで提供されます。 |
| BLOB のソフト削除が有効になっているが、バージョン管理は無効になっている場合 | 層に関係なく、すべての既存の論理的な削除のスナップショットがコンテンツ全体の長さで。 |
既知の制限
アーカイブアクセス層ではブロブのスナップショットを作成することはできません。
Data Lake Gen2 アカウントのスナップショット機能については、新規顧客の受け入れを終了しました。 代わりに、blobソフト削除、AzCopy、またはVaulted Backupを使いましょう。
アクティブなスナップショットがある間は、削除コールに
x-ms-delete-snapshotsを含めない限り、blob は削除できません。オブジェクトレプリケーションはスナップショットを複製しません。
スナップショットの作成後は変更できません。
スナップショットでリースを取得することはできません。
監視とトラブルシューティング
ベースのブロブは削除できません:ブロブにはアクティブなスナップショットがあります。 Blob の削除を
x-ms-delete-snapshots: includeと組み合わせて使用すると、両方を同時に削除できます。ベースのブロブを削除した後、スナップショットが消えました:ベースブロブを削除すると、ブロブソフト削除が有効でない限りスナップショットが永久に消えます。 誤って削除しないようにソフト削除を有効にしてください。
私のスナップショットコストは予想より高く、ブロブのアクセス階層を明示的に変更すると、ユニークブロックだけでなく全コンテンツの長さに支払うことになります。 可能な限り、アクティブなスナップショットを持つブロブでの明示的なティア変更は避けてください。
スナップショットの閲覧と在庫管理:ポータル内では、「 Show Blob snapshots 」が有効になっていると、ストレージブラウザのブロブの下にスナップショットが表示されます。 アカウント全体でスナップショット数やストレージ使用量のインベントリを取得するには、Azure Storage Blob Inventory と Azure Monitor の BlobCapacity メトリックを使いましょう。