Управление версиями BLOB-объекта

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

Внимание

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

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

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

Идентификатор версии может определять текущую или предыдущую версию. У блоба может быть только одна текущая версия.

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

На рисунке ниже показана схема создания версий при операциях записи и повышения уровня предыдущей версии до текущей.

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

Внимание

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

Версии BLOB-объектов неизменяемы. Невозможно изменить содержимое или метаданные существующей версии блоба.

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

Версия 2019-10-10 и выше REST API служба хранилища Azure поддерживает версионирование BLOB-объектов.

Внимание

Управление версиями BLOB-объектов не поможет восстановить данные после случайного удаления учётной записи хранения или контейнера. Чтобы предотвратить случайное удаление учетной записи хранения, настройте блокировку в ресурсе учетной записи хранения. Дополнительные сведения о блокировке учетной записи хранения см. в статье Применение блокировки Azure Resource Manager к учетной записи хранилища.

Идентификатор версии

Каждая версия blob имеет уникальный идентификатор версии. Значение идентификатора версии — это временная метка, соответствующая моменту обновления BLOB-объекта. Вы присваиваете ID версии при создании версии.

Вы можете прочитать или удалить конкретную версию blob, используя её ID версии. Если не указать ID версии, операция нацелена на текущую версию.

При вызове операции записи для создания или изменения объекта BLOB служба хранилища Azure возвращает заголовок x-ms-version-id в ответе. Этот заголовок содержит идентификатор версии текущей версии blob-а, созданной операцией записи.

Идентификатор версии остаётся прежним на протяжении всего срока действия версии.

Управление версиями при операциях записи

Когда вы включаете версионирование blob, каждая операция записи в blob создаёт новую версию. Операции записи могут быть следующие: Разместить BLOB-объект, Разместить список блоков, Копировать BLOB-объект и Задать метаданные BLOB-объекта.

Если операция записи создаёт новый blob, полученный blob становится текущей версией blob. Если операция записи изменяет существующий blob, текущая версия становится предыдущей, а новая текущая версия захватывает обновлённый blob.

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

Схема, показывающая, как операции записи влияют на BLOB-объекты с версиями.

Примечание.

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

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

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

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

Управление версиями при операциях удаления

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

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

Диаграмма, показывающая удаление версионного блоба.

Чтобы удалить определенную версию BLOB-объекта, укажите идентификатор этой версии в операции удаления. Если вы также включите blob soft delete для аккаунта хранения, система сохраняет версию до истечения периода сохранения soft delete.

При записи новых данных в 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 являются частью рекомендуемой конфигурации защиты данных для учетных записей хранения. Дополнительные сведения о рекомендациях Microsoft по защите данных см. в обзоре защиты данных.

Перезапись BLOB-объекта

Если для блобов в учетной записи хранения включены версионирование и мягкое удаление, то при перезаписи блоба автоматически создается новая версия. Новая версия не подвергается обратимому удалению и не удаляется по истечении периода хранения для обратимого удаления. "Мягко удалённые моментальные снимки не создаются."

Удаление BLOB-объекта или версии

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

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

Чтобы удалить предыдущую версию BLOB-объекта, вызовите операцию Delete Blob (Удаление BLOB-объекта) и укажите идентификатор версии.

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

Схема, показывающая удаление версии с включенным мягким удалением.

Восстановление временно удаленной версии

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

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

Следующая схема показывает, как восстановить мягко удалённые версии blob с помощью операции Undelete Blob и как восстановить текущую версию blob с помощью операции Copy Blob .

Схема восстановления мягко удаленных версий.

После окончания периода мягкого удаления все версии с мягко удаленными блобами удаляются навсегда.

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

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

Внимание

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

Сделать снимок BLOB-объекта при включенном управлении версиями

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

При создании снимка версионного BLOB-объекта вы одновременно создаёте и новую версию. Вы также создаёте новую текущую версию, когда делаете снимок.

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

Схема, показывающая версии BLOB.

Авторизация операций в версиях BLOB-объектов

Вы можете авторизовать доступ к версиям blob, используя один из следующих подходов:

  • Используйте Azure role-based access control (Azure RBAC) для предоставления разрешений принципалу безопасности Microsoft Entra. Microsoft рекомендует использовать Microsoft Entra ID для обеспечения повышенной безопасности и простоты использования. Дополнительные сведения об использовании Microsoft Entra ID с операциями больших двоичных объектов см. в разделе Authorize access to data in служба хранилища Azure.
  • Используйте подпись общего доступа (SAS) для делегирования доступа между версиями blob. Укажите идентификатор версии для подписанного типа ресурса bv, который представляет версию BLOB-объекта, чтобы создать токен SAS для операций с конкретной версией. Дополнительные сведения о сигнатурах общего доступа (SAS) см. в статье Grant limited access to служба хранилища Azure resources using shared access signatures (SAS).
  • Используйте ключи доступа к учетной записи для авторизации операций против blob-версий с помощью Shared Key. Дополнительные сведения см. в статье Авторизация с помощью общего ключа.

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

Действие RBAC в Azure для удаления версии BLOB

В следующей таблице показано, какие действия Azure RBAC разрешают удаление BLOB или версии BLOB.

Описание Операция службы BLOB Требуются действия с данными в Azure RBAC поддержка встроенных ролей Azure
Удаление текущей версии Удалить Blob Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete Участник данных хранилища BLOB-объектов
Удаление предыдущей версии Удалить Blob Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action Владелец данных хранилища BLOB-объектов

Параметры общей подписи доступа (SAS)

Подписанный ресурс для версии BLOB — bv. Дополнительные сведения см. в статьях Создание службы SAS или Создание SAS для делегирования пользователей.

В следующей таблице показано разрешение, необходимое для удаления версии BLOB-объекта на SAS.

Разрешение Символ URI Разрешенные операции
Удалить x Удалите версию BLOB.

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

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

Оплата за версии BLOB-объектов, такие как моментальные снимки, производится по той же ставке, что и активные данные. То, как вы платите за версии, зависит от того, установили ли вы явно уровень для текущих или предыдущих версий blob (или снимков). Дополнительные сведения о уровнях доступа к BLOB-объектам см. в разделе «Горячий», «Прохладный», «Холодный» и «Архивный» для данных BLOB-объектов.

Если вы не меняете уровень доступа BLOB-объекта или его версии, вы платите за уникальные блоки данных в этом BLOB-объекте, его версиях и всех его снимках. Дополнительные сведения см. в разделе «Выставление счетов, если уровень BLOB-объекта не задан явно».

Если вы меняете blob или уровень версии, вы платите за весь объект, независимо от того, окажутся ли blob и версия в итоге в одном уровне. Для получения дополнительной информации см. раздел «Биллинг, когда уровень blob явно установлен».

Примечание.

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

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

Дополнительные сведения о выставлении счетов за моментальные снимки BLOB-объектов см. в разделе Моментальные снимки BLOB-объектов.

Для учётных записей хранения, использующих уровень Smart Tier, плата за версии и моментальные снимки взимается исходя из полного объёма содержимого. Дополнительные сведения см. в статье "Оптимизация затрат с помощью интеллектуального уровня".

Выставление счетов, если вы явно не задаете уровень BLOB-объекта

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

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

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

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

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

Сценарий 1

В сценарии 1 BLOB-объект имеет предыдущую версию. BLOB-объект не обновлялся с момента создания версии, поэтому с вас взимается плата только за уникальные блоки 1, 2 и 3.

Диаграмма 1, показывающая выставление счетов за уникальные блоки в базовом блобе и предыдущей версии.

Сценарий 2

Во втором сценарии вы обновляете один блок (блок 3 на диаграмме) в блобе. Несмотря на то, что обновленный блок содержит те же данные и тот же идентификатор, он не совпадает с блоком 3 в предыдущей версии. В результате вы платите за четыре блока.

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

Сценарий 3

В третьем сценарии вы обновляете BLOB-объект, но не обновляете версию. В текущем блобе вы заменяете блок 3 на блок 4, но предыдущая версия всё равно отражает блок 3. В результате вы платите за четыре блока.

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

Сценарий 4

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

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

Биллинг, когда уровень blob явно установлен

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

Перемещение BLOB-объекта на новый уровень

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

При установке уровня доступа BLOB-объекта… Тогда вам выставляются счета за...
явно указав на текущую или предыдущую версию. Полная длина содержимого этой версии. Версии, для которых уровень не установлен явно, оплачиваются только за уникальные блоки.1
Архивировать Полная длина содержимого всех версий и моментальных снимков. 1.

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

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

Схема, показывающая, как осуществляется оплата за объекты при явной установке уровня версионированного BLOB.

Нельзя отменить явную установку уровня для blob, версии или снимка. Если вы перемещаете блоб на новый уровень, а затем возвращаете его на исходный уровень, вы платите за полную длину контента объекта, даже если он делится блоками с другими объектами исходного уровня.

Операции, которые явно задают уровень для BLOB-объекта, версии или моментального снимка:

Удаление BLOB-объекта при включенном мягком удалении

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

Поддержка функций

Поддержка этой функции может повлиять на включение протокола Data Lake Storage 2-го поколения, сетевой файловой системы (NFS) 3.0 или протокола SSH-передачи файлов (SFTP). Если вы включили любую из этих возможностей, ознакомьтесь с поддержкой функций Хранилище BLOB-объектов в учетных записях служба хранилища Azure для оценки поддержки этой функции.

Версионирование не поддерживается для blobs, которые вы загружаете с помощью API Data Lake Storage.

См. также

  • Last updated on