Поделиться через


Копирование BLOB-объекта

Операция Copy Blob копирует большой двоичный объект в место назначения в учетной записи хранения.

В версии 2012-02-12 и более поздних версиях источником Copy Blob операции может быть зафиксированный большой двоичный объект в любой учетной записи хранения Azure.

Начиная с версии 2015-02-21, источником Copy Blob операции может быть файл Azure в любой учетной записи хранения Azure.

Замечание

Только учетные записи хранения, созданные 7 июня 2012 г. или позже, разрешают Copy Blob копирование операции из другой учетной записи хранения.

Просьба

Можно создать запрос Copy Blob следующим образом. Мы рекомендуем HTTPS. Замените myaccount именем учетной записи хранения, mycontainer — именем контейнера, а myblob — именем целевого BLOB-объекта.

Начиная с версии 2013-08-15, вы можете указать подписанный URL-адрес (SAS) для целевого BLOB-объекта, если он находится в той же учетной записи, что и исходный BLOB-объект. Начиная с версии 2015-04-05, вы также можете указать подписанный URL-адрес для целевого BLOB-объекта, если он находится в другой учетной записи хранения.

URI запроса метода PUT Версия HTTP
https://myaccount.blob.core.windows.net/mycontainer/myblob HTTP/1.1

URI для эмулируемой службы хранилища

При отправке запроса к эмулированной службе хранения укажите имя узла эмулятора и порт хранилища BLOB-объектов Azure как 127.0.0.1:10000, а затем имя эмулируемой учетной записи хранения:

URI запроса метода PUT Версия HTTP
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob HTTP/1.1

Дополнительные сведения см. в статье Использование эмулятора Azurite для разработки локальной службы хранилища Azure.

Параметры URI

Можно указать следующие дополнительные параметры в URI запроса:

Параметр Описание
timeout Необязательно. Параметр timeout выражается в секундах. Дополнительные сведения см. в статье Установка времени ожидания для операций Хранилища BLOB-объектов.

Заголовки запросов

В следующей таблице описаны обязательные и необязательные заголовки запросов:

Заголовок запроса Описание
Authorization Обязательное. Указывает схему авторизации, имя учетной записи и подпись. Дополнительные сведения см. в статье Авторизация запросов к службе хранилища Azure.
Date или x-ms-date Обязательное. Указывает универсальное время (UTC) для запроса. Дополнительные сведения см. в статье Авторизация запросов к службе хранилища Azure.
x-ms-version Требуется для всех авторизованных запросов. Дополнительные сведения см. в разделе Управление версиями служб хранилища Azure.
x-ms-meta-name:value Необязательно. Указывает определяемую пользователем пару "имя-значение", связанную с большим двоичным объектом. Если пары имя/значение не указаны, операция копирует метаданные из исходного большого двоичного объекта или файла в целевой большой двоичный объект. Если указана одна или несколько пар "имя-значение", целевой BLOB-объект создается с указанными метаданными, а метаданные не копируются из исходного BLOB-объекта или файла.

Начиная с версии 2009-09-19, имена метаданных должны соответствовать правилам именования для идентификаторов C#. Дополнительные сведения см. в статье Именование контейнеров, больших двоичных объектов и метаданных и ссылки на них.
x-ms-tags Необязательно. Задает заданные теги в кодировке строки запроса на большом двоичном объекте. Теги не копируются из скопированного источника. Дополнительные сведения см. в разделе Замечания. Поддерживается в версии 2019-12-12 и более поздних версий.
x-ms-source-if-modified-since Необязательно. Некоторое значение DateTime. Укажите этот условный заголовок, чтобы скопировать большой двоичный объект, только если исходный большой двоичный объект был изменен с указанной даты и времени. Если исходный большой двоичный объект не был изменен, хранилище BLOB-объектов возвращает код состояния 412 (сбой предварительного условия). Вы не можете указать этот заголовок, если источником является файл Azure.
x-ms-source-if-unmodified-since Необязательно. Некоторое значение DateTime. Укажите этот условный заголовок, чтобы скопировать большой двоичный объект, только если исходный большой двоичный объект не был изменен с указанной даты и времени. Если исходный большой двоичный объект был изменен, хранилище BLOB-объектов возвращает код состояния 412 (сбой предварительных условий). Вы не можете указать этот заголовок, если источником является файл Azure.
x-ms-source-if-match Необязательно. Значение типа ETag. Укажите этот условный заголовок, чтобы скопировать исходный большой двоичный объект только в том случае, если его ETag значение совпадает с указанным. Если значения не совпадают, хранилище BLOB-объектов возвращает код состояния 412 (сбой предварительного условия). Вы не можете указать этот заголовок, если источником является файл Azure.
x-ms-source-if-none-match Необязательно. Значение типа ETag. Укажите этот условный заголовок, чтобы скопировать большой двоичный объект только в том случае, если его ETag значение не соответствует указанному значению. Если значения идентичны, хранилище BLOB-объектов возвращает код состояния 412 (сбой предварительных условий). Вы не можете указать этот заголовок, если источником является файл Azure.
If-Modified-Since Необязательно. Некоторое значение DateTime. Укажите этот условный заголовок, чтобы скопировать большой двоичный объект, только если целевой большой двоичный объект был изменен с указанной даты и времени. Если целевой BLOB-объект не был изменен, хранилище BLOB-объектов возвращает код состояния 412 (сбой предварительного условия).
If-Unmodified-Since Необязательно. Некоторое значение DateTime. Укажите этот условный заголовок, чтобы скопировать большой двоичный объект, только если целевой большой двоичный объект не был изменен с указанной даты и времени. Если целевой большой двоичный объект был изменен, хранилище BLOB-объектов возвращает код состояния 412 (сбой предварительных условий).
If-Match Необязательно. Значение типа ETag. Укажите значение для этого условного ETag заголовка, чтобы скопировать BLOB-объект только в том случае, если указанное ETag значение совпадает со значением ETag для существующего BLOB-объекта назначения. Если значения не совпадают, хранилище BLOB-объектов возвращает код состояния 412 (сбой предварительного условия).
If-None-Match Необязательно. Значение ETag или подстановочный знак (*).

Укажите ETag значение для этого условного заголовка, чтобы скопировать большой двоичный объект только в том случае, если указанное ETag значение не совпадает со значением ETag для целевого большого двоичного объекта.

Укажите подстановочный знак (*) для выполнения операции, только если целевой большой двоичный объект не существует.

Если указанное условие не выполнено, хранилище BLOB-объектов возвращает код состояния 412 (сбой предварительных условий).
x-ms-copy-source:name Обязательное. Указывает имя исходного большого двоичного объекта или файла.

Начиная с версии 2012-02-12, это значение может быть URL-адресом длиной до 2 кибибайт (КБ), указывающим большой двоичный объект. Значение должно быть закодировано в URL-адресе так, как оно отображается в URI запроса.

Операция чтения исходного BLOB-объекта в той же учетной записи хранения может быть авторизована с помощью общего ключа. Начиная с версии 2017-11-09, вы также можете использовать идентификатор Microsoft Entra для авторизации операции чтения в исходном большом двоичном объекте. Однако если источником является большой двоичный объект в другой учетной записи хранения, исходный большой двоичный объект должен быть общедоступным или доступ к нему должен быть авторизован с помощью подписанного URL-адреса. Если исходный большой двоичный объект является общедоступным, авторизация для выполнения операции копирования не требуется.

Начиная с версии 2015-02-21, исходным объектом может быть файл в Файлах Azure. Если исходный объект является файлом, который будет скопирован в большой двоичный объект, то исходный файл должен быть авторизован с помощью подписанного URL-адреса, независимо от того, находится ли он в той же учетной записи или в другой.

Только учетные записи хранения, созданные 7 июня 2012 г. или позже, разрешают Copy Blob копирование операции из другой учетной записи хранения.

Ниже приведены некоторые примеры URL-адресов исходного объекта:

- https://myaccount.blob.core.windows.net/mycontainer/myblob
- https://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime>
- https://myaccount.blob.core.windows.net/mycontainer/myblob?versionid=<DateTime>

Если исходный объект является файлом в Файлах Azure, исходный URL-адрес имеет следующий формат. Обратите внимание, что URL-адрес должен содержать действительный маркер SAS для файла.

- https://myaccount.file.core.windows.net/myshare/mydirectorypath/myfile?sastoken

В версиях до 2012-02-12 большие двоичные объекты могут быть скопированы только в пределах одной учетной записи, а имя источника может использовать следующие форматы:

- Blob в именованном контейнере: /accountName/containerName/blobName
- Снимок в именованном контейнере: /accountName/containerName/blobName?snapshot=<DateTime>
- Большой двоичный объект в корневом контейнере: /accountName/blobName
- Снимок в корневом контейнере: /accountName/blobName?snapshot=<DateTime>
x-ms-lease-id:<ID> Обязательно, если целевой BLOB-объект имеет активную аренду. Идентификатор аренды, указанный для этого заголовка, должен соответствовать идентификатору аренды целевого большого двоичного объекта. Если запрос не содержит идентификатор аренды или идентификатор недействителен, операция завершается ошибкой с кодом состояния 412 (сбой условия).

Если этот заголовок указан и целевой BLOB-объект в настоящее время не имеет активной аренды, операция завершается ошибкой с кодом состояния 412 (сбой предварительного условия).

В версии 2012-02-12 и более поздних версиях это значение должно указывать активную бесконечную аренду для арендованного большого двоичного объекта. Код аренды с ограниченным сроком действия завершается ошибкой с кодом состояния 412 (Ошибка предварительного условия).
x-ms-source-lease-id: <ID> Необязательно для версий до 2012-02-12 (не поддерживается в 2012-02-12 и позже). Укажите этот заголовок для выполнения Copy Blob операции только в том случае, если предоставленный идентификатор аренды совпадает с активным идентификатором аренды исходного большого двоичного объекта.

Если этот заголовок указан и исходный большой двоичный объект в настоящее время не имеет активной аренды, операция завершается ошибкой с кодом состояния 412 (сбой предварительного условия).
x-ms-client-request-id Необязательно. Предоставляет созданное клиентом непрозрачное значение с ограничением символов 1-KiB, записанным в журналах при настройке ведения журнала. Настоятельно рекомендуется использовать этот заголовок для сопоставления действий на стороне клиента с запросами, получаемыми сервером.
x-ms-access-tier Необязательно. Указывает уровень, который должен быть задан для целевого BLOB-объекта. Этот заголовок предназначен для страничных BLOB-объектов в премиум-аккаунте только с версией 2017-04-17 и более поздними. Полный список поддерживаемых уровней см. в статье Высокопроизводительное хранилище класса Premium и управляемые диски для виртуальных машин. Этот заголовок поддерживается в версии 2018-11-09 и более поздних для блочных BLOB-объектов. Распределение блочных BLOB-объектов по уровням поддерживается в учетных записях Хранилища BLOB-объектов или общего назначения версии 2. Допустимыми значениями являются Hot, Cool, Cold и Archive. Примечание. УровеньCold поддерживается для версии 2021-12-02 и более поздних версий. Подробные сведения о распределении по уровням блочных BLOB-объектов см. в статье Горячий, холодный и архивный уровни хранилища.
x-ms-rehydrate-priority Необязательно. Указывает приоритет, с помощью которого необходимо восстановить архивный большой двоичный объект. Этот заголовок поддерживается в версии 2019-02-02 и более поздних версиях для блочных BLOB-объектов. Допустимые значения — High и Standard. Вы можете задать приоритет для большого двоичного объекта только один раз. Этот заголовок будет игнорироваться при последующих запросах к тому же BLOB-объекту. Приоритет по умолчанию без этого заголовка — Standard.
x-ms-seal-blob Необязательно. Поддерживается на версии 2019-12-12 или более поздней. Этот заголовок действителен только для добавленных больших двоичных объектов. Он запечатывает целевой BLOB-объект после завершения операции копирования.
x-ms-immutability-policy-until-date Версия 2020-06-12 и выше. Указывает дату хранения до, которая должна быть установлена для большого двоичного объекта. Это дата, до которой большой двоичный объект может быть защищен от изменения или удаления. Он следует RFC1123 формату.
x-ms-immutability-policy-mode Версия 2020-06-12 и выше. Указывает режим политики неизменяемости, который должен быть задан для большого двоичного объекта. Допустимые значения — unlocked и locked. Значение unlocked указывает, что пользователь может изменить политику, увеличив или уменьшив срок хранения до. Значение locked указывает на то, что эти действия запрещены.
x-ms-legal-hold Версия 2020-06-12 и выше. Указывает удержание по юридическим причинам для большого двоичного объекта. Допустимые значения — true и false.

Эта операция поддерживает x-ms-if-tags успешное выполнение заголовков и x-ms-source-if-tags условных заголовков только в том случае, если выполняется указанное условие. Дополнительные сведения см. в разделе Указание условных заголовков для операций хранилища BLOB-объектов.

Основное содержание запроса

Нет.

Ответ

Ответ включает код состояния HTTP и набор заголовков ответа.

Код состояния

В версии 2012-02-12 и более поздних версиях при успешной операции возвращается код состояния 202 (Принято).

В версиях до 2012-02-12 при успешной операции возвращается код состояния 201 (Создано).

Сведения о кодах состояния см. в коды состояния и коды ошибок.

Заголовки ответа

Ответ для этой операции содержит следующие заголовки. Ответ также может включать дополнительные стандартные заголовки HTTP. Все стандартные заголовки соответствуют спецификации протокола HTTP/1.1.

Заголовок ответа Описание
ETag В версии 2012-02-12 и более поздних, если копирование завершено, этот заголовок содержит ETag значение целевого BLOB-объекта. Если копирование не завершено, заголовок содержит ETag значение пустого большого двоичного объекта, созданного в начале операции копирования.

В версиях до 2012-02-12 этот заголовок возвращает ETag значение целевого BLOB-объекта.

В версии 2011-08-18 и более поздних версиях ETag значение указано в кавычках.
Last-Modified Возвращает дату и время завершения операции копирования в целевой BLOB-объект.
x-ms-request-id Уникально идентифицирует выполненный запрос. Этот заголовок можно использовать для устранения неполадок запроса. Дополнительные сведения см. в статье Устранение неполадок с операциями API.
x-ms-version Указывает версию хранилища BLOB-объектов, которая используется для выполнения запроса. Этот заголовок возвращается для запросов к версии 2009-09-19 и более поздних версий.
Date Значение даты и времени в формате UTC, указывающее время отправки ответа службой.
x-ms-copy-id: <id> Версия 2012-02-12 и выше. Предоставляет строковый идентификатор для этой операции копирования. Используйте Get Blob или Get Blob Properties для проверки состояния этой операции копирования или передачи Abort Copy Blob для отмены ожидающей операции копирования.
x-ms-copy-status: <success ¦ pending> Версия 2012-02-12 и выше. Указывает состояние операции копирования со следующими значениями:

- success: Операция завершилась успешно.
- pending: Операция выполняется.
x-ms-version-id: <DateTime> Версия 2019-12-12 и выше. Однозначно идентифицирует большой двоичный объект по его версии. Вы можете использовать это непрозрачное значение в последующих запросах на доступ к этой версии большого двоичного объекта.
x-ms-client-request-id Можно использовать для устранения неполадок запросов и соответствующих ответов. Значение этого заголовка равно значению заголовка x-ms-client-request-id, если оно присутствует в запросе, а значение — не более 1024 видимых символов ASCII. Если в запросе отсутствует заголовок x-ms-client-request-id, этот заголовок не будет присутствовать в ответе.

Основная часть ответа

Нет.

Пример ответа

Следующий код представляет собой пример ответа на запрос на копирование большого двоичного объекта:

Response Status:  
HTTP/1.1 202 Accepted  
  
Response Headers:   
Last-Modified: <date>   
ETag: "0x8CEB669D794AFE2"  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-request-id: cc6b209a-b593-4be1-a38a-dde7c106f402  
x-ms-version: 2015-02-21  
x-ms-copy-id: 1f812371-a41d-49e6-b123-f4b542e851c5  
x-ms-copy-status: pending
x-ms-version-id: <DateTime>  
Date: <date>  
  

Авторизация

Авторизация требуется при вызове любой операции доступа к данным в службе хранилища Azure. В следующей таблице описывается, как можно авторизовать конечные и исходные объекты для операции Copy Blob:

Тип объекта Авторизация по Microsoft Entra ID Авторизация с помощью подписанного URL-адреса (SAS) Авторизация с помощью общего ключа (или Shared Key Lite)
Целевой большой двоичный объект Да Да Да
Исходный большой двоичный объект в той же учетной записи хранения Да Да Да
Исходный большой двоичный объект в другой учетной записи хранения нет Да нет

Если в заголовке запроса указаны теги x-ms-tags , вызывающий объект должен соответствовать требованиям авторизации операции Set Blob Tags .

Вы можете авторизовать операцию Copy Blob, как описано ниже. Обратите внимание, что исходный большой двоичный объект в другой учетной записи хранения должен быть авторизован отдельно с помощью маркера SAS с разрешением на чтение (r). Дополнительные сведения об авторизации исходных BLOB-объектов см. в сведениях о заголовке x-ms-copy-sourceзапроса.

Это важно

Корпорация Майкрософт рекомендует использовать идентификатор Microsoft Entra с управляемыми удостоверениями для авторизации запросов в службу хранилища Azure. Идентификатор Microsoft Entra обеспечивает более высокую безопасность и удобство использования по сравнению с авторизацией общего ключа.

Служба хранилища Azure поддерживает использование идентификатора Microsoft Entra для авторизации запросов к данным BLOB-объектов. С помощью идентификатора Microsoft Entra можно использовать управление доступом на основе ролей Azure (Azure RBAC) для предоставления разрешений субъекту безопасности. Субъект безопасности может быть пользователем, группой, субъектом-службой приложений или управляемым удостоверением Azure. Принципал безопасности проходит проверку подлинности с помощью Microsoft Entra ID, чтобы вернуть токен OAuth 2.0. Затем маркер можно использовать для авторизации запроса к службе BLOB-объектов.

Дополнительные сведения об авторизации с помощью идентификатора Microsoft Entra см. в статье Авторизация доступа к большим двоичным объектам с помощью идентификатора Microsoft Entra ID.

Разрешения

Ниже приведены действия RBAC, необходимые для пользователя Microsoft Entra, группы, управляемого удостоверения или субъекта-службы для вызова операции Copy Blob и минимально привилегированной встроенной роли Azure RBAC, которая включает в себя следующее:

Целевой большой двоичный объект

Исходный большой двоичный объект в той же учетной записи хранения

Дополнительные сведения о назначении ролей с помощью Azure RBAC см. в статье Назначение роли Azure для доступа к данным BLOB-объектов.

Замечания

В версии 2012-02-12 и более поздних версиях операция может завершаться Copy Blob асинхронно. Эта операция возвращает идентификатор копии, который можно использовать для проверки или отмены операции копирования. Из-за асинхронного характера операции копирования хранилище BLOB-объектов копирует BLOB-объекты по мере возможности. Служба BLOB-объектов копирует большие двоичные объекты, когда ресурсы сервера не используются другими задачами, поэтому не гарантируется, что копирование будет запущено немедленно или завершено в указанный период времени.

Исходным большим двоичным объектом для операции копирования может быть блочный большой двоичный объект, добавочный большой двоичный объект, страничный большой двоичный объект или моментальный снимок. Если целевой BLOB-объект уже существует, он должен иметь тот же тип BLOB-объекта, что и исходный BLOB-объект. Любой существующий целевой BLOB-объект будет перезаписан. Вы не можете изменить целевой BLOB-объект во время выполнения операции копирования.

В версии 2015-02-21 и более поздних версиях источником для операции копирования также может быть файл в Файлах Azure. Если источником является файл, то местом назначения должен быть блочный большой двоичный объект.

Несколько ожидающих Copy Blob операций в учетной записи могут обрабатываться последовательно. Целевой BLOB-объект может иметь только одну незавершенную Copy Blob операцию. Другими словами, большой двоичный объект не может быть местом назначения для нескольких ожидающих Copy Blob операций. Попытка скопировать большой двоичный объект назначения в целевой большой двоичный объект, в котором уже ожидает операции копирования, завершается ошибкой с кодом состояния 409 (конфликт).

Только учетные записи хранения, созданные 7 июня 2012 г. или позже, разрешают Copy Blob копирование операции из другой учетной записи хранения. Попытка копирования из другой учетной записи хранения в учетную запись, созданную до 7 июня 2012 г., завершается ошибкой с кодом состояния 400 (недопустимый запрос).

Операция Copy Blob всегда копирует весь исходный большой двоичный объект или файл. Копирование диапазона байтов или набора блоков не поддерживается.

Операция Copy Blob может принимать любую из следующих форм:

  • Вы можете скопировать исходный BLOB-объект в целевой BLOB-объект с другим именем. Целевой BLOB-объект может быть существующим BLOB-объектом того же типа (блочный, добавочный или страничный) или новым BLOB-объектом, созданным операцией копирования.

  • Вы можете скопировать исходный BLOB-объект в целевой BLOB-объект с тем же именем, фактически заменив целевой BLOB-объект. Такая операция копирования удаляет все незафиксированные блокировки и перезаписывает метаданные большого двоичного объекта.

  • Вы можете скопировать исходный файл в Файлах Azure в целевой BLOB-объект. Целевой BLOB-объект может быть существующим блочным BLOB-объектом или новым блочным BLOB-объектом, созданным операцией копирования. Копирование из файлов в страничные BLOB-объекты или добавление BLOB-объектов не поддерживается.

  • Вы можете скопировать моментальный снимок поверх его базового большого двоичного объекта. Повысив моментальный снимок до уровня базового блоба, вы можете восстановить более раннюю версию блоба.

  • Вы можете скопировать моментальный снимок в целевой BLOB-объект с другим именем. Полученный целевой блоб будет доступным для записи и не станет снимком.

При копировании из страничного BLOB-объекта хранилище BLOB-объектов создает целевой страничный BLOB-объект длины исходного BLOB-объекта. Изначально страничный BLOB-объект содержит все нули. Затем перечисляются диапазоны исходных страниц, а непустые диапазоны копируются.

Для блочного или добавочного BLOB-объекта хранилище BLOB-объектов создает зафиксированный BLOB-объект нулевой длины перед возвращением из этой операции.

При копировании из блочного BLOB-объекта копируются все зафиксированные блокировки и их идентификаторы блокировок. Незафиксированные блокировки не копируются. В конце операции копирования целевой BLOB-объект имеет то же количество зафиксированных блоков, что и исходный.

При копировании из добавочного BLOB-объекта копируются все зафиксированные блокировки. В конце операции копирования целевой BLOB-объект будет иметь меньше или такое же количество зафиксированных блоков, как и исходный BLOB-объект.

Для всех типов BLOB-объектов можно вызвать Get Blob или Get Blob Properties на целевой BLOB-объект, чтобы проверить состояние операции копирования. Последний большой двоичный объект будет зафиксирован после завершения операции копирования.

Если источник операции копирования предоставляет ETag значения, любые изменения в источнике во время выполнения операции копирования приведут к сбою этой операции. Попытка изменить целевой BLOB-объект во время выполнения копирования завершится ошибкой с кодом состояния 409 (конфликт). Если целевой BLOB-объект имеет бесконечную аренду, идентификатор аренды должен быть передан в Copy Blob. Аренда с ограниченным сроком действия не допускается.

Значение ETag блочного BLOB-объекта изменяется в момент Copy Blob начала и завершения операции. Значение ETag страничного BLOB-объекта изменяется в начале Copy Blob операции и продолжает часто меняться во время операции копирования. Содержимое блочного большого двоичного объекта становится видимым с помощью Get команды только после завершения операции полного копирования.

Копирование свойств, тегов и метаданных BLOB-объектов

При копировании большого двоичного объекта следующие системные свойства копируются в целевой большой двоичный объект с теми же значениями:

  • Content-Type

  • Content-Encoding

  • Content-Language

  • Content-Length

  • Cache-Control

  • Content-MD5

  • Content-Disposition

  • x-ms-blob-sequence-number (только для страничных BLOB-объектов)

  • x-ms-committed-block-count (только для добавления больших двоичных объектов и только для версии 2015-02-21)

Зафиксированный список блокировок исходного большого двоичного объекта также копируется в целевой большой двоичный объект, если он является блочным. Любые незафиксированные блокировки не копируются.

Целевой BLOB-объект всегда имеет тот же размер, что и исходный BLOB-объект. Значение Content-Length заголовка для целевого BLOB-объекта совпадает со значением этого заголовка для исходного BLOB-объекта.

Если исходный и целевой BLOB-объекты совпадают, Copy Blob удаляются все незафиксированные блокировки. Если в этом случае указаны метаданные, существующие метаданные перезаписываются новыми метаданными.

x-ms-tags Если заголовок содержит теги для целевого BLOB-объекта, они должны быть закодированы в строке запроса. Ключи и значения тегов должны соответствовать требованиям к именованию и длине, указанным в разделе Задание тегов BLOB-объектов.

Заголовок x-ms-tags может содержать до 2 килобит тегов. Если вам нужно больше тегов, воспользуйтесь Set Blob Tags этой операцией.

x-ms-tags Если в заголовке не указаны теги, они не копируются из исходного большого двоичного объекта.

Копирование арендованного большого двоичного объекта

Операция Copy Blob считывает данные только из исходного большого двоичного объекта, поэтому состояние аренды исходного большого двоичного объекта не имеет значения. Copy Blob Однако операция сохраняет ETag значение исходного большого двоичного объекта при запуске операции копирования. Если значение ETag изменяется до завершения операции копирования, операция завершается ошибкой. Вы можете предотвратить изменения исходного большого двоичного объекта, арендовав его во время операции копирования.

Если целевой BLOB-объект имеет активную бесконечную аренду, необходимо указать его идентификатор аренды в вызове Copy Blob операции. Если указанная аренда является активной арендой с конечной продолжительностью, этот вызов завершается ошибкой с кодом состояния 412 (ошибка предварительного условия). Пока операция копирования находится в ожидании, любая операция аренды целевого BLOB-объекта завершается сбоем с кодом состояния 409 (конфликт). Таким образом, бесконечная аренда целевого BLOB-объекта блокируется во время операции копирования, независимо от того, копируете ли вы в целевой BLOB-объект с именем, отличным от исходного, копируете в целевой BLOB-объект с тем же именем, что и исходный, или создаете моментальный снимок для его базового BLOB-объекта.

Если клиент указывает идентификатор аренды для большого двоичного объекта, который еще не существует, хранилище BLOB-объектов возвращает код состояния 412 (сбой предварительного условия) для запросов, выполненных в версии 2013-08-15 и более поздних версиях. Для более ранних версий Хранилище BLOB-объектов возвращает код состояния 201 (создано).

Копирование моментальных снимков BLOB-объектов

При копировании исходного BLOB-объекта все моментальные снимки или версии исходного BLOB-объекта не копируются в место назначения. Когда целевой BLOB-объект перезаписывается копией, все моментальные снимки или версии, связанные с целевым BLOB-объектом, остаются неизменными под его именем.

Вы можете выполнить операцию копирования, чтобы повысить уровень моментального снимка над базовым BLOB-объектом, если он находится на оперативном уровне (горячем или холодном). Таким образом, вы можете восстановить более раннюю версию большого двоичного объекта. Снимок остается, но его назначение перезаписывается копией, которую можно как читать, так и записывать.

Копирование версий BLOB-объектов

Вы можете выполнить операцию копирования, чтобы повысить уровень версии по базовому BLOB-объекту, если он находится на оперативном уровне (горячем или холодном). Таким образом, вы можете восстановить более раннюю версию большого двоичного объекта. Версия остается, но ее назначение перезаписывается копией, которую можно как читать, так и записывать.

Копирование архивного большого двоичного объекта

Начиная с версии 2018-11-09, вы можете скопировать архивный большой двоичный объект в новый большой двоичный объект в той же учетной записи хранения. Исходный большой двоичный объект остается на уровне архива. Если исходный большой двоичный объект является архивным, запрос должен содержать x-ms-access-tier заголовок, указывающий уровень целевого большого двоичного объекта. Целевой большой двоичный объект должен находиться на оперативном уровне. Вы не можете копировать в большой двоичный объект на архивном уровне.

Начиная с версии 2021-02-12, вы можете скопировать архивированный большой двоичный объект на сетевой уровень в другой учетной записи хранения, если целевая учетная запись находится в том же регионе, что и исходная учетная запись.

Запрос может завершиться ошибкой, если исходный большой двоичный объект восстанавливается.

Подробные сведения о распределении по уровням на уровне блочных BLOB-объектов см. в статье Горячий, холодный и архивный уровни хранилища.

Работа с ожидающей операцией копирования (версия 2012-02-12 и более поздняя)

Copy Blob Если операция завершается асинхронно, используйте следующую таблицу, чтобы определить следующий шаг на основе возвращенного кода состояния:

Код состояния Значение
202 (принято), x-ms-copy-status: success Операция копирования завершена успешно.
202 (принято), состояние x-ms-copy-status: ожидание Операция копирования не завершена. Опрашивайте целевой BLOB-объект с помощью Get Blob Properties проверки x-ms-copy-status заголовка до тех пор, пока операция не завершится или не завершится сбоем.
4xx, 500 или 503 Сбой операции копирования.

Во время и после операции Copy Blob свойства целевого BLOB-объекта содержат идентификатор Copy Blob копии операции и URL-адрес исходного BLOB-объекта. После завершения операции Хранилище BLOB-объектов записывает значение времени и результата (success, failedили aborted) в свойства конечного BLOB-объекта. Если операция имеет failed результат, заголовок x-ms-copy-status-description содержит строку сведений об ошибке.

Ожидающая Copy Blob операция имеет двухнедельное время ожидания. Попытка копирования, которая не завершилась по истечении двух недель, и оставляет пустой большой двоичный объект с x-ms-copy-status полем 500 failed и значением x-ms-copy-status-description 500 (OperationCancelled). Периодические неустранимые ошибки, которые могут возникать во время операции копирования, могут препятствовать выполнению операции, но не привести к сбою. В этих случаях x-ms-copy-status-description описывает периодические ошибки.

Любая попытка изменить или создать моментальный снимок целевого BLOB-объекта во время операции копирования завершится ошибкой с кодом состояния 409 (конфликт), "Выполняется копирование BLOB-объекта".

Если вы вызовете Abort Copy Blob операцию, вы увидите x-ms-copy-status:aborted заголовок. Целевой BLOB-объект будет иметь нетронутые метаданные и длину BLOB-объекта 0 байт. Вы можете повторить исходный вызов Copy Blob , чтобы повторить операцию копирования.

Copy Blob Если операция завершается синхронно, используйте следующую таблицу для определения состояния операции копирования:

Код состояния Значение
202 (принято), x-ms-copy-status: success Операция копирования завершена успешно.
4xx, 500 или 503 Сбой операции копирования.

Уровень наследуется для уровней хранилища Premium. Для блочных BLOB-объектов перезапись целевого BLOB-объекта унаследует горячий или холодный уровень от назначения, если x-ms-access-tier он не указан. Перезапись архивного большого двоичного объекта завершится ошибкой. Подробные сведения о распределении по уровням на уровне блочных BLOB-объектов см. в статье Горячий, холодный и архивный уровни хранилища.

Выставление счетов

Запросы цен могут возникать от клиентов, использующих API хранилища BLOB-объектов, непосредственно через REST API хранилища BLOB-объектов или из клиентской библиотеки службы хранилища Azure. Эти запросы начисляют плату за транзакцию. Тип транзакции влияет на то, как взимается учетная запись. Например, транзакции чтения начисляются в другую категорию выставления счетов, чем операции записи. В следующей таблице показана категория выставления счетов для запросов Copy Blob на основе типа учетной записи хранения:

Операция Тип учётной записи хранилища Категория выставления счетов
Копирование BLOB-объекта (целевая учетная запись1) Блочный BLOB-объект категории "Премиум".
Стандартная версия общего назначения v2
Стандартная версия общего назначения 1
Операции записи
Копирование BLOB-объекта (исходная учетная запись2) Блочный BLOB-объект категории "Премиум".
Стандартная версия общего назначения v2
Стандартная версия общего назначения 1
Операции чтения

1Целевая учетная запись взимается за одну транзакцию, чтобы инициировать запись.
2Если исходный объект находится в другой учетной записи, исходная учетная запись выполняет одну транзакцию для каждого запроса на чтение исходного объекта.

Дополнительные сведения о ценах для указанных категорий выставления счетов см. в цен на хранилище BLOB-объектов Azure.

Целевая учетная запись также несет транзакционные издержки при каждом запросе на отмену операции копирования (см. раздел Отмена копирования BLOB-объекта) или на проверку состояния операции копирования (см. раздел Получение BLOB-объекта или Получение свойств BLOB-объекта).

Кроме того, если исходная и целевая учетные записи находятся в разных регионах (например, Северная и Южная части США), пропускная способность, используемая для передачи запроса, оплачивается исходящей учетной записью хранения в качестве исходящего трафика. Исходящие данные между учетными записями в одном регионе бесплатны.

При копировании исходного BLOB-объекта в целевой BLOB-объект с другим именем в той же учетной записи используются дополнительные ресурсы хранилища для нового BLOB-объекта. Затем операция копирования приводит к списанию платы за использование емкости учетной записи хранения для этих дополнительных ресурсов. Однако если имена исходного и целевого BLOB-объектов совпадают в одной учетной записи (например, при повышении уровня моментального снимка до базового BLOB-объекта), дополнительная плата не взимается, за исключением дополнительных метаданных копий, хранящихся в версии 2012-02-12 и более поздних.

Когда моментальный снимок заменяется базовым BLOB-объектом, моментальный и базовый BLOB-объекты становятся идентичными. Они совместно используют блоки или страницы, поэтому операция копирования не приводит к взиманию дополнительной платы за использование емкости учетной записи хранения. Однако при копировании моментального снимка в целевой BLOB-объект с другим именем взимается дополнительная плата за ресурсы хранилища, которые использует полученный новый BLOB-объект. Два больших двоичных объекта с разными именами не могут совместно использовать блоки или страницы, даже если они идентичны. Дополнительные сведения о сценариях затрат на моментальные снимки см. в статье Общие сведения о том, как начисляются расходы на моментальные снимки.

См. также

Авторизация запросов в службу хранилища Azure
Коды состояний и ошибок
коды ошибок хранилища BLOB-объектов
Понимание того, как на моментальные снимки начисляются расходы
Прерывание копирования большого двоичного объекта