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

Статья
04/11/2023

Операция Copy Blob копирует BLOB-объект в место назначения в учетной записи хранилища.

В версии 2012-02-12 и более поздних версиях источником операции Copy Blob может быть зафиксированный 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-объект создается с указанными метаданными и метаданные не копируются из исходного BLOB-объекта или файла. Начиная с версии 2009-09-19 имена метаданных должны соответствовать правилам именования для идентификаторов C#. Дополнительные сведения см. в статье Именование контейнеров, больших двоичных объектов и метаданных и ссылки на нее.
`x-ms-tags`	Необязательный элемент. Задает заданные теги в кодировке строки запроса для большого двоичного объекта. Теги не копируются из источника копирования. Дополнительные сведения см. в разделе Примечания. Поддерживается в версии 2019-12-12 и более поздних версиях.
`x-ms-source-if-modified-since`	Необязательный элемент. Значение `DateTime`. Задайте этот заголовок условной операции, чтобы BLOB-объект копировался, только если BLOB-объект источника был изменен, начиная с указанной даты-времени. Если исходный BLOB-объект не был изменен, хранилище BLOB-объектов возвращает код состояния 412 (сбой предварительного условия). Этот заголовок нельзя указать, если источником является файл Azure.
`x-ms-source-if-unmodified-since`	Необязательный элемент. Значение `DateTime`. Задайте этот заголовок условной операции, чтобы BLOB-объект копировался, только если BLOB-объект источника не был изменен, начиная с указанной даты-времени. Если исходный BLOB-объект был изменен, хранилище BLOB-объектов возвращает код состояния 412 (сбой условия). Этот заголовок нельзя указать, если источником является файл Azure.
`x-ms-source-if-match`	Необязательный элемент. Значение `ETag`. Укажите этот условный заголовок, чтобы скопировать исходный BLOB-объект, только если его `ETag` значение совпадает с указанным значением. Если значения не совпадают, хранилище BLOB-объектов возвращает код состояния 412 (сбой предварительного условия). Этот заголовок нельзя указать, если источником является файл Azure.
`x-ms-source-if-none-match`	Необязательный элемент. Значение `ETag`. Укажите этот условный заголовок для копирования большого двоичного объекта, только если его `ETag` значение не соответствует указанному значению. Если значения идентичны, хранилище BLOB-объектов возвращает код состояния 412 (сбой предварительного условия). Этот заголовок нельзя указать, если источником является файл Azure.
`If-Modified-Since`	Необязательный элемент. Значение `DateTime`. Задайте этот заголовок условной операции, чтобы копировать BLOB-объект, только если BLOB-объект назначения был изменен после указанной даты-времени. Если целевой BLOB-объект не был изменен, хранилище BLOB-объектов возвращает код состояния 412 (сбой предварительного условия).
`If-Unmodified-Since`	Необязательный элемент. Значение `DateTime`. Задайте этот заголовок условной операции, чтобы копировать BLOB-объект, только если BLOB-объект назначения не был изменен после указанной даты-времени. Если целевой BLOB-объект был изменен, хранилище BLOB-объектов возвращает код состояния 412 (сбой предварительного условия).
`If-Match`	Необязательный элемент. Значение `ETag`. `ETag` Укажите значение для этого условного заголовка, чтобы скопировать большой двоичный объект, только если указанное `ETag` значение совпадает со значением `ETag` для существующего целевого BLOB-объекта. Если значения не совпадают, хранилище BLOB-объектов возвращает код состояния 412 (сбой предварительного условия).
`If-None-Match`	Необязательный элемент. Значение `ETag` или подстановочный знак (). `ETag` Укажите значение для этого условного заголовка, чтобы скопировать большой двоичный объект только в том случае, если указанное `ETag` значение не соответствует значению `ETag` целевого BLOB-объекта. Укажите подстановочный знак () для выполнения операции, только если целевой BLOB-объект не существует. Если указанное условие не выполняется, хранилище BLOB-объектов возвращает код состояния 412 (сбой предварительного условия).
`x-ms-copy-source:name`	Обязательный. Указывает имя исходного большого двоичного объекта или файла. Начиная с версии 2012-02-12 это значение может быть URL-адресом длиной до 2 кибибайт (КиБ), указывающим большой двоичный объект. Значение должно быть закодировано в формате URL-адреса, которое будет отображаться в URI запроса. Операцию чтения в исходном BLOB-объекте в той же учетной записи хранения можно авторизовать с помощью общего ключа. Начиная с версии 2017-11-09, вы также можете использовать Microsoft Entra ID для авторизации операции чтения в исходном BLOB-объекте. Однако если источником является BLOB-объект в другой учетной записи хранения, исходный BLOB-объект должен быть общедоступным или доступ к нему должен быть авторизован с помощью подписанного URL-адреса. Если исходный BLOB-объект является общедоступным, для выполнения операции копирования авторизация не требуется. Начиная с версии 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` В версиях до 12.02.2012 большие двоичные объекты можно копировать только в одной учетной записи, а имя источника может использовать следующие форматы: — BLOB-объект в именованном контейнере: `/accountName/containerName/blobName` — Моментальный снимок в именованном контейнере: `/accountName/containerName/blobName?snapshot=<DateTime>` — BLOB-объект в корневом контейнере: `/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>`	Необязательно для версий до 12.02.2012 (не поддерживается в 12.02.2012 и более поздних версиях). Укажите этот заголовок для выполнения `Copy Blob` операции, только если предоставленный идентификатор аренды совпадает с идентификатором активной аренды исходного BLOB-объекта. Если этот заголовок указан, а исходный BLOB-объект в настоящее время не имеет активной аренды, операция завершается ошибкой с кодом состояния 412 (сбой предварительного условия).
`x-ms-client-request-id`	Необязательный элемент. Предоставляет созданное клиентом непрозрачное значение с ограничением в 1 КиБ символов, которое записывается в журналы при настройке ведения журнала. Мы настоятельно рекомендуем использовать этот заголовок для сопоставления действий на стороне клиента с запросами, получаемыми сервером.
`x-ms-access-tier`	Необязательный элемент. Указывает уровень, который необходимо задать для целевого большого двоичного объекта. Этот заголовок предназначен для страничных BLOB-объектов в учетной записи premium только с версии 2017-04-17 и более поздних версий. Полный список поддерживаемых уровней см. в статье Высокопроизводительное хранилище класса Premium и управляемые диски для виртуальных машин. Этот заголовок поддерживается в версии 2018-11-09 и более поздних для блочных BLOB-объектов. Блочные blob-объекты поддерживаются в хранилище BLOB-объектов или общего назначения учетных записях версии 2. Допустимые значения: `Hot`, `Cool`и `ArchiveCold` . Примечание:`Cold` tier поддерживается для версии 2021-12-02 и более поздних версий. Подробные сведения о разных уровнях блочных BLOB-объектов см. в разделе Горячий, холодный и архивный уровни хранилища.
`x-ms-rehydrate-priority`	Необязательный элемент. Указывает приоритет восстановления архивного большого двоичного объекта. Этот заголовок поддерживается в версии 2019-02-02 и более поздних для блочных BLOB-объектов. Допустимые значения: `High` и `Standard`. Вы можете задать приоритет для большого двоичного объекта только один раз. Этот заголовок будет игнорироваться при последующих запросах к тому же большому двоичному объекту. Приоритет по умолчанию без этого заголовка — `Standard`.
`x-ms-seal-blob`	Необязательный элемент. Поддерживается в версии 2019-12-12 или более поздней. Этот заголовок действителен только для добавочных BLOB-объектов. Он запечатывает целевой BLOB-объект после завершения операции копирования.
`x-ms-immutability-policy-until-date`	Версия 12.06.2020 и более поздняя. Указывает дату хранения до установки в большом двоичном объекте. Это дата, до которой blob-объект может быть защищен от изменения или удаления. Он соответствует RFC1123 формате.
`x-ms-immutability-policy-mode`	Версия 12.06.2020 и более поздняя. Указывает режим политики неизменяемости для большого двоичного объекта. Допустимые значения: `unlocked` и `locked`. Значение `unlocked` указывает, что пользователь может изменить политику путем увеличения или уменьшения срока хранения до даты. Значение `locked` указывает, что эти действия запрещены.
`x-ms-legal-hold`	Версия 12.06.2020 и более поздняя. Указывает юридическое удержание большого двоичного объекта. Допустимые значения: `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` значение целевого большого двоичного объекта. Если копирование не завершено, заголовок содержит `ETag` значение пустого большого двоичного объекта, созданного в начале операции копирования. В версиях до 12.02.2012 этот заголовок возвращает `ETag` значение для целевого большого двоичного объекта. В версии 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>`	Версия 12.02.2012 и более поздняя. Предоставляет строковый идентификатор для этой операции копирования. Используйте с `Get Blob` или `Get Blob Properties` , чтобы проверка состояние этой операции копирования, или передайте в `Abort Copy Blob` , чтобы отменить ожидающие операции копирования.
`x-ms-copy-status: <success ¦ pending>`	Версия 12.02.2012 и более поздняя. Указывает состояние операции копирования со следующими значениями: - `success`: операция успешно завершена. - `pending`: операция выполняется.
`x-ms-version-id: <DateTime>`	Версия 12.12.2019 и более поздняя. Уникально идентифицирует BLOB-объект по его версии. Это непрозрачное значение можно использовать в последующих запросах для доступа к этой версии большого двоичного объекта.
`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)	Авторизация с общим ключом (или общий ключ Lite)
Целевой BLOB-объект	Да	Да	Да
Исходный BLOB-объект в той же учетной записи хранения	Да	Да	Да
Исходный BLOB-объект в другой учетной записи хранения	Нет	Да	Нет

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

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

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

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

Разрешения

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

Целевой BLOB-объект

Действие Azure RBAC:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write (для записи в существующий BLOB-объект) или Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action (для записи нового BLOB-объекта в назначение)
Встроенная роль с минимальными привилегиями:Участник данных BLOB-объектов хранилища

Исходный BLOB-объект в одной учетной записи хранения

Действие Azure RBAC:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Встроенная роль с минимальными привилегиями:читатель данных BLOB-объектов хранилища

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

Подписанный URL-адрес (SAS) обеспечивает безопасный делегированный доступ к ресурсам в учетной записи хранения. С помощью SAS вы можете детально контролировать доступ клиента к данным. Вы можете указать, к какому ресурсу может обращаться клиент, какие у него есть разрешения для этих ресурсов и как долго будет действителен SAS.

Операция Copy Blob поддерживает три типа подписанных URL-адресов: SAS делегирования пользователей, SAS службы и SAS учетной записи.

В целях обеспечения безопасности рекомендуется использовать Microsoft Entra учетные данные, а не ключ учетной записи хранения, который проще скомпрометировать. Если для проектирования приложения требуются подписанные URL-адреса, по возможности используйте учетные данные Microsoft Entra, чтобы создать SAS для делегирования пользователей.

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

SAS для делегирования пользователей

SAS для делегирования пользователей защищен Microsoft Entra учетными данными, а также разрешениями, указанными для SAS.

Copy Blob Для вызова операции с использованием маркера SAS, делегированного ресурсу BLOB-объекта, требуется следующее разрешение в составе маркера SAS делегирования пользователей.

Операция	Тип объекта	Подписанное разрешение
Копирование BLOB-объекта	Целевой BLOB-объект (новый)	Create (c) или Write (w)
Копирование BLOB-объекта	Целевой BLOB-объект (существующий)	Запись (w)
Копирование BLOB-объекта	Исходный BLOB-объект (в одной учетной записи хранения)	Чтение (r)
Копирование BLOB-объекта	Исходный BLOB-объект (в другой учетной записи хранения)	Чтение (r)

Дополнительные сведения о SAS для делегирования пользователей см. в статье Создание SAS для делегирования пользователей.

SAS для службы

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

Copy Blob Для вызова операции с использованием маркера SAS, делегированного ресурсу BLOB-объекта, требуется следующее разрешение в составе маркера SAS службы.

Операция	Тип объекта	Подписанное разрешение
Копирование BLOB-объекта	Целевой BLOB-объект (новый)	Create (c) или Write (w)
Копирование BLOB-объекта	Целевой BLOB-объект (существующий)	Запись (w)
Копирование BLOB-объекта	Исходный BLOB-объект (в одной учетной записи хранения)	Чтение (r)
Копирование BLOB-объекта	Исходный BLOB-объект (в другой учетной записи хранения)	Чтение (r)

Дополнительные сведения о SAS службы см. в статье Создание SAS службы.

SAS для учетной записи

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

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

Операция	Тип объекта	Подписанная служба	Подписанный тип ресурса	Подписанное разрешение
Копирование BLOB-объекта	Целевой BLOB-объект (новый)	Большой двоичный объект (b)	Объект (o)	Create (c) или Write (w)
Копирование BLOB-объекта	Целевой BLOB-объект (существующий)	Большой двоичный объект (b)	Объект (o)	Запись (w)
Копирование BLOB-объекта	Исходный BLOB-объект (в одной учетной записи хранения)	Большой двоичный объект (b)	Объект (o)	Чтение (r)
Копирование BLOB-объекта	Исходный BLOB-объект (в другой учетной записи хранения)	Большой двоичный объект (b)	Объект (o)	Чтение (r)

Дополнительные сведения о SAS учетной записи см. в статье Создание SAS учетной записи.

Операция Copy Blob поддерживает авторизацию с помощью общего ключа. Авторизация с помощью ключей учетной записи не рекомендуется в большинстве сценариев, так как она менее безопасна.

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

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

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

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

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

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

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

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

Вы можете скопировать исходный BLOB-объект в целевой BLOB-объект с другим именем. Конечный BLOB-объект может быть существующим BLOB-объектом того же типа (блочный, добавочный или страничный) или новым BLOB-объектом, создаваемым операцией копирования.
Вы можете скопировать исходный BLOB-объект в целевой BLOB-объект с тем же именем, фактически заменив целевой BLOB-объект. Такая операция копирования приводит к удалению всех незафиксированных блокировок и перезаписи метаданных BLOB-объекта.
Исходный файл можно скопировать в Файлы Azure в целевой BLOB-объект. Конечным BLOB-объектом может быть существующий блочный BLOB-объект или новый блочный BLOB-объект, создаваемый операцией копирования. Копирование из файлов в страничные BLOB-объекты или добавочные BLOB-объекты не поддерживается.
Можно скопировать моментальный снимок и заменить им исходный большой двоичный объект. Повысив уровень моментального снимка до базового большого двоичного объекта, можно восстановить более раннюю версию большого двоичного объекта.
Вы можете скопировать snapshot в целевой 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 запуске операции и продолжает часто меняться во время операции копирования. Содержимое блочного BLOB-объекта отображается с помощью Get команды только после завершения операции полного копирования.

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

При копировании большого двоичного объекта в целевой 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 (только для добавочных BLOB-объектов и только для версии 2015-02-21)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Код состояния	Значение
202 (принято), x-ms-copy-status: success	Операция копирования успешно завершена.
202 (принято), x-ms-copy-status: pending	Операция копирования не завершена. Опрашивает целевой 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 операция имеет двухнедельное время ожидания. Попытка копирования, которая не была завершена через две недели, истекает и оставляет пустой BLOB-объект с x-ms-copy-status полем , для которого x-ms-copy-status-description задано значение failed , а для параметра задано значение 500 (OperationCancelled). Периодические неустранимые ошибки, которые могут возникать во время операции копирования, могут препятствовать выполнению операции, но не привести к сбою. В этих случаях в x-ms-copy-status-description содержится описание временных ошибок.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также раздел

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