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


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

Операция 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#. Дополнительные сведения см. в статье Именование контейнеров, BLOB-объектов и метаданных и ссылки на нее.
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 и более поздних это значение должно указывать активную бесконечную аренду для арендованного BLOB-объекта. Сбой идентификатора аренды конечной длительности с кодом состояния 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-объекта. Этот заголовок предназначен для страничных BLOB-объектов в учетной записи уровня "Премиум" только с версии 2017-04-17 и более поздних версий. Полный список поддерживаемых уровней см. в статье Высокопроизводительное хранилище класса Premium и управляемые диски для виртуальных машин. Этот заголовок поддерживается в версии 2018-11-09 и более поздних для блочных BLOB-объектов. В хранилище BLOB-объектов или общего назначения учетных записях версии 2 поддерживается разнесение по уровням блочных BLOB-объектов. Допустимые значения: Hot, ColdCoolи Archive. Примечание: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 значение для целевого 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> Версия 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> Версия 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) Авторизация с общим ключом (или общий ключ Lite)
Целевой BLOB-объект Да Да Да
Исходный BLOB-объект в той же учетной записи хранения Да Да Да
Исходный BLOB-объект в другой учетной записи хранения Нет Да Нет

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

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

Важно!

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

Служба хранилища 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-объект

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

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

Комментарии

В версии 2012-02-12 и более поздних версиях Copy 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-объекте, чтобы проверка состояние операции копирования. Окончательный 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-объект. Значение заголовка 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-объект с тем же именем, что и у источника, или повышение уровня 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-объекта (целевая учетная запись1) Блочный BLOB-объект (ценовая категории "Премиум")
Общего назначения версии 2 (цен. категория "Стандартный")
Стандартная общего назначения версии 1
Операции записи
Копирование BLOB-объекта (исходная учетная запись2) Блочный BLOB-объект (ценовая категории "Премиум")
Общего назначения версии 2 (цен. категория "Стандартный")
Стандартная общего назначения версии 1
Операции чтения

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

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

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

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

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

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

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

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