BLOB の削除の取り消し

この操作により Undelete Blob 、論理的に削除された BLOB の内容とメタデータ、および関連付けられている論理的に削除されたスナップショットが復元されます。

Undelete Blob はバージョン 2017-07-29 以降でのみサポートされています。

要求

要求は Undelete Blob 次のように構築できます。 HTTPS が推奨されます。 myaccount をストレージ アカウントの名前に置き換えます。

PUT メソッド要求 URI	HTTP バージョン
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=undelete	HTTP/1.1

エミュレートされたストレージ サービス URI

エミュレートされたストレージ サービスに対して要求を行う場合は、エミュレーターのホスト名とAzure Blob Storageポートを として127.0.0.1:10000指定し、その後にエミュレートされたストレージ アカウント名を指定します。

PUT メソッド要求 URI	HTTP バージョン
http://127.0.0.1:10000/ devstoreaccount1/mycontainer/myblob?comp=undelete	HTTP/1.1

詳細については、「 ローカル Azure Storage 開発に Azurite エミュレーターを使用する」を参照してください。

URI パラメーター

要求 URI には、次の追加パラメーターを指定できます。

パラメーター	説明
timeout	省略可能。 timeout パラメーターは、秒単位で表されます。 詳細については、「 Blob Storage 操作のタイムアウトの設定」を参照してください。

要求ヘッダー (すべての BLOB の種類)

次の表では、すべての BLOB の種類に必要な要求ヘッダーと省略可能な要求ヘッダーについて説明します。

要求ヘッダー	説明
Authorization	必須。 承認スキーム、アカウント名、署名を指定します。 詳細については、「Azure Storage への要求を承認する」をご覧ください。
Date または x-ms-date	必須。 要求に対して協定世界時 (UTC) を指定します。 詳細については、「Azure Storage への要求を承認する」をご覧ください。
x-ms-version	すべての承認された要求に必要です。 この要求に使用する操作のバージョンを指定します。 詳細については、「Azure Storage サービスのバージョン管理」を参照してください。
x-ms-undelete-source	省略可能。 バージョン 2020-08-04 以降。 階層型名前空間で有効になっているアカウントの場合のみ。 削除を取り消す論理的に削除された BLOB のパス。 形式は blobPath?deletionid=<id> です。 アカウントとコンテナー名はパスに含まれません。 DeletionId は、論理的に削除された BLOB の一意識別子です。 これを取得するには、階層型名前空間で有効にするアカウントの REST API を使用して List Blobs 、論理的に削除された BLOB を一覧表示します。 パスはパーセントエンコードする必要があります。
x-ms-client-request-id	省略可能。 ログ記録の構成時にログに記録される 1 kibibyte (KiB) 文字制限を使用して、クライアントによって生成された不透明な値を提供します。 このヘッダーを使用して、クライアント側のアクティビティとサーバーが受信する要求を関連付けるよう強くお勧めします。 詳細については、「Azure Blob Storageの監視」を参照してください。

要求本文

[なし] :

Response

応答には、HTTP 状態コードおよび一連の応答ヘッダーが含まれています。

status code

操作に成功すると、状態コード 200 (OK) が返されます。 状態コードの詳細については、「 状態とエラー コード」を参照してください。

応答ヘッダー

この操作の応答には、次のヘッダーが含まれています。 応答には、追加の標準 HTTP ヘッダーを含めることもできます。 すべての標準ヘッダーは 、HTTP/1.1 プロトコル仕様に準拠しています。

構文	説明
x-ms-request-id	このヘッダーは、行われた要求を一意に識別し、要求のトラブルシューティングに使用できます。 詳細については、「 API 操作のトラブルシューティング」を参照してください。
x-ms-version	要求の実行に使用される Blob Storage のバージョンを示します。
Date	応答が開始された時刻を示す UTC 日付/時刻値。 サービスによってこの値が生成されます。
x-ms-client-request-id	このヘッダーを使用して、要求と対応する応答のトラブルシューティングを行うことができます。 このヘッダーの値は、要求に存在する x-ms-client-request-id 場合は、ヘッダーの値と同じです。 この値は、最大 1,024 文字の可視 ASCII 文字です。 ヘッダーが x-ms-client-request-id 要求に存在しない場合、このヘッダーは応答に存在しません。

応答本文

[なし] :

承認

Azure Storage でデータ アクセス操作を呼び出す場合は、承認が必要です。 操作は、以下で Undelete Blob 説明するように承認できます。

重要

Microsoft では、マネージド ID でMicrosoft Entra IDを使用して、Azure Storage への要求を承認することをお勧めします。 Microsoft Entra IDは、共有キーの承認と比較して優れたセキュリティと使いやすさを提供します。

Microsoft Entra ID (推奨)

Azure Storage では、Microsoft Entra ID を使用して BLOB データへの要求を承認することがサポートされています。 Microsoft Entra IDでは、Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、セキュリティ プリンシパルにアクセス許可を付与できます。 セキュリティ プリンシパルには、ユーザー、グループ、アプリケーション サービス プリンシパル、または Azure マネージド ID を指定できます。 セキュリティ プリンシパルは、OAuth 2.0 トークンを返すためにMicrosoft Entra IDによって認証されます。 その後、そのトークンを、Blob service に対する要求を認可するために使用できます。

注意

Microsoft では、マネージド ID でMicrosoft Entra IDを使用して、Azure Storage への要求を承認することをお勧めします。 Microsoft Entra IDは、共有キーの承認と比較して優れたセキュリティと使いやすさを提供します。

Microsoft Entra IDを使用した承認の詳細については、「Microsoft Entra IDを使用して BLOB へのアクセスを承認する」を参照してください。

アクセス許可

Microsoft Entraユーザー、グループ、マネージド ID、またはサービス プリンシパルが操作を呼び出Undelete Blobすために必要な RBAC アクションと、このアクションを含む最小特権の組み込み Azure RBAC ロールを次に示します。

• Azure RBAC アクション:Microsoft.Storage/storageAccounts/blobServices/containers/write
• 最小特権の組み込みロール:ストレージ BLOB データ共同作成者

Azure RBAC を使用したロールの割り当ての詳細については、「 BLOB データにアクセスするための Azure ロールの割り当て」を参照してください。

共有アクセス署名 (SAS)

Shared Access Signature (SAS) は、ストレージ アカウント内のリソースへのセキュリティで保護された委任されたアクセスを提供します。 SAS を使用すると、クライアントがデータにアクセスする方法をきめ細かく制御できます。 クライアントがアクセスできるリソース、それらのリソースに対するアクセス許可、および SAS が有効な期間を指定できます。

この操作では Undelete Blob 、 ユーザー委任 SAS、 サービス SAS、 アカウント SAS の 3 種類の共有アクセス署名がサポートされています。

セキュリティのベスト プラクティスとして、ストレージ アカウント キーではなくMicrosoft Entra資格情報を使用することをお勧めします。これは、より簡単に侵害される可能性があります。 アプリケーション設計で共有アクセス署名が必要な場合は、可能であれば、Microsoft Entra資格情報を使用してユーザー委任 SAS を作成します。

ストレージ アカウントに対して共有キー アクセスが許可されていない場合、サービス SAS トークンまたはアカウント SAS トークンは、Blob Storage への要求では許可されません。 詳細については、「 共有キーの禁止が SAS トークンにどのように影響するかを理解する」を参照してください。

ユーザー委任 SAS

ユーザー委任 SAS は、Microsoft Entra資格情報と、SAS に対して指定されたアクセス許可によっても保護されます。

コンテナー リソースに Undelete Blob 委任された SAS トークンを使用して操作を呼び出すには、ユーザー委任 SAS トークンの一部として 書き込み (w) アクセス許可が必要です。

ユーザー委任 SAS の詳細については、「ユーザー委任 SAS のCreate」を参照してください。

サービス SAS

サービス SAS は、ストレージ アカウント キーで保護されます。 サービス SAS は、BLOB ストレージなどの単一の Azure Storage サービス内のリソースへのアクセスを委任します。

コンテナー リソースに Undelete Blob 委任された SAS トークンを使用して操作を呼び出すには、サービス SAS トークンの一部として 書き込み (w) アクセス許可が必要です。

サービス SAS の詳細については、「サービス SAS のCreate」を参照してください。

アカウント SAS

アカウント SAS は、ストレージアカウント キーで保護されます。 アカウント SAS は、1 つ以上のストレージ サービスのリソースへのアクセスを委任します。 サービスまたはユーザー委任 SAS を介して実行できるすべての操作は、アカウント SAS を介しても実行できます。

次の表は、アクセスを委任するときに指定する署名付きリソースの種類と署名付きアクセス許可を示しています。

操作	署名済みサービス	署名されたリソースの種類	署名されたアクセス許可
BLOB の削除の取り消し	BLOB (b)	コンテナー (c)	書き込み (w)

アカウント SAS の詳細については、「アカウント SAS のCreate」を参照してください。

共有キー

この操作では Undelete Blob 、 共有キーの承認がサポートされています。 アカウント キーを使用した承認は、セキュリティが低く、ほとんどのシナリオでは推奨されません。

可能な場合は、ストレージ アカウントの共有キーの承認を禁止することをお勧めします。 詳細については、「共有キーによる承認の防止」を参照してください。

注釈

論理的に削除された BLOB の削除を取り消すと、BLOB と関連するスナップショットは、他の API を使用して操作に使用できます。 論理的に削除されていない BLOB または論理的に削除されたスナップショットがない BLOB の削除を取り消すと、操作は変更されずに成功します。

請求

価格要求は、Blob Storage REST API を介して直接、または Azure Storage クライアント ライブラリから Blob Storage API を使用するクライアントから送信できます。 これらの要求では、トランザクションあたりの料金が発生します。 トランザクションの種類は、アカウントの課金方法に影響します。 たとえば、読み取りトランザクションは、書き込みトランザクションとは異なる課金カテゴリに計上されます。 次の表は、ストレージ アカウントの種類に基づく要求の課金カテゴリ Undelete Blob を示しています。

操作	ストレージ アカウントの種類	課金カテゴリ
BLOB の削除の取り消し	Premium ブロック BLOB Standard 汎用 v2 Standard 汎用 v1	書き込み操作

指定した課金カテゴリの価格については、「Azure Blob Storage価格」を参照してください。

こちらもご覧ください

Azure Storage への要求を承認する
状態とエラー コードBLOB の削除