次の方法で共有

コンテナーを復元する

  • [アーティクル]

操作により Restore Container 、論理的に削除されたコンテナーの内容とプロパティが、指定したコンテナーに復元されます。 Restore Containerこの操作は、バージョン2019-12-12以降で使用できます。

要求

共有キー、アカウント共有 Restore Container アクセス署名承認、またはロールベースのアクセス制御を使用して承認された有効な要求を使用して、要求を構築できます。

Method 要求 URI HTTP バージョン
PUT https://myaccount.blob.core.windows.net/destinationcontainer?restype=container&comp=undelete HTTP/1.1
PUT https://myaccount.blob.core.windows.net/destinationcontainer?restype=container&comp=undelete&sv=validsastoken HTTP/1.1

URI パラメーター

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

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

要求ヘッダー

必須要求ヘッダーと省略可能な要求ヘッダーを次の表に示します。

要求ヘッダー 説明
Authorization 必須。 承認スキーム、アカウント名、署名を指定します。 詳細については、「Azure Storage への要求を承認する」をご覧ください。
Date or x-ms-date 必須。 要求に対して協定世界時 (UTC) を指定します。 詳細については、「Azure Storage への要求を承認する」をご覧ください。
x-ms-version すべての承認された要求に必要です。 この要求に使用する操作のバージョンを指定します。 この操作の場合、バージョンは 以降である 2018-03-28 必要があります。 詳細については、「Azure Storage サービスのバージョン管理」を参照してください。
x-ms-client-request-id 省略可能。 ログ記録の構成時にログに記録される 1 kibibyte (KiB) 文字制限を使用して、クライアントによって生成された不透明な値を提供します。 このヘッダーを使用して、クライアント側のアクティビティとサーバーが受信する要求を関連付けるよう強くお勧めします。 詳細については、「Azure Blob Storageの監視」を参照してください。
x-ms-deleted-container-name 必須。 このヘッダーを使用して、復元する必要がある論理的に削除されたコンテナーを一意に識別します。
x-ms-deleted-container-version 必須。 このヘッダーを使用して、復元する必要がある論理的に削除されたコンテナーを一意に識別します。 この値は、操作のdeletedクエリ パラメーターList Containersで値をinclude指定することから取得できます。 詳細については、「コンテナーの 一覧表示」を参照してください。

要求本文

[なし] :

Response

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

status code

操作が正常に終了すると、状態コード 201 (Created) が返されます。 状態コードの詳細については、「 状態とエラー コード」を参照してください。

応答ヘッダー

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

応答ヘッダー 説明
x-ms-request-id 行われた要求を一意に識別し、要求のトラブルシューティングに使用できます。 詳細については、「 API 操作のトラブルシューティング」を参照してください。
x-ms-version バージョン 2009-09-19 以降。 要求の実行に使用Azure Blob Storageのバージョンを示します。
Date 応答が開始された時刻を示す UTC 日付/時刻値。 サービスによってこの値が生成されます。
Content-Length 要求本文の長さです。 この操作では、コンテンツの長さは常に 0 です。

応答本文

[なし] :

応答のサンプル

Response Status:  
HTTP/1.1 201 OK  
  
Response Headers:  
Date: Mon, 15 Jun 2020 12:43:08 GMT  
x-ms-version: 2019-12-12  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
Content-Length: 0

承認

Azure Storage でデータ アクセス操作を呼び出すときは、承認が必要です。 操作は、次の Restore Container セクションで説明するように承認できます。

重要

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

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

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

アクセス許可

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

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

注釈

  • ストレージ リソース プロバイダーを使用して、アカウントのコンテナー削除保持ポリシーを設定できます。
  • 指定したコンテナーは、操作が Restore Container 実行されるときに存在してはなりません。
  • 指定したコンテナーが存在する場合、 Restore Container 操作は 409 (競合) で失敗します。
  • 論理的に削除されたコンテナーが存在しない場合、操作の Restore Container ソースとして既に使用されている場合、または保持日数を超えている場合、操作は 409 (競合) で失敗します。

請求

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

操作 ストレージ アカウントの種類 課金カテゴリ
コンテナーを復元する Premium ブロック BLOB
Standard 汎用 v2
Standard 汎用 v1		 コンテナー操作の一覧表示とCreate

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