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


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

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

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

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

Дополнительные сведения о рекомендациях Майкрософт по защите данных см. в разделе Общие сведения о защите данных.

Внимание

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

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

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

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

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

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

Diagram showing how blob versioning works

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

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

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

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

Внимание

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

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

Каждая версия BLOB-объекта определяется по уникальному идентификатору версии. Значение идентификатора версии — это метка времени обновления BLOB-объекта. Идентификатор версии назначается при создании версии.

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

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

Идентификатор версии остается неизменным в течение времени существования версии.

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

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

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

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

Diagram showing how write operations affect versioned blobs.

Примечание.

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

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

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

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

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

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

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

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

Diagram showing deletion of versioned blob.

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

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

Diagram showing re-creation of versioned blob after deletion.

Уровни доступа

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

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

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

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

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

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

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

Управление версиями объектов реплика зависит от управления версиями БОЛЬШИХ двоичных объектов. Прежде чем отключить управление версиями BLOB-объектов, необходимо удалить все политики реплика объектов в учетной записи. Дополнительные сведения о репликации объектов см. в разделе Репликация объектов для блочных BLOB-объектов.

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

Diagram showing that modification of a current version after versioning is disabled creates a blob that isn't a version.

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

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

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

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

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

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

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

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

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

Diagram showing deletion of a version with soft delete enabled.

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

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

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

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

Diagram showing how to restore soft-deleted versions.

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

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

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

Внимание

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

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

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

При создании моментального снимка BLOB-объекта с управлением версиями создается новая версия одновременно с созданием моментального снимка. При создании моментального снимка также создается новая текущая версия.

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

Diagram showing snapshots of a versioned blob.

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

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

  • С помощью управления доступом на основе ролей Azure (Azure RBAC) для предоставления разрешений субъекту безопасности Microsoft Entra. Корпорация Майкрософт рекомендует использовать идентификатор Microsoft Entra для обеспечения повышенной безопасности и простоты использования. Дополнительные сведения об использовании идентификатора Microsoft Entra с операциями больших двоичных объектов см. в статье "Авторизация доступа к данным в служба хранилища Azure".
  • С помощью подписанного URL-адреса (SAS) для делегирования доступа к версиям BLOB-объектов. Укажите идентификатор версии для подписанного типа ресурса bv, представляющего версию BLOB-объекта, чтобы создать маркер SAS для операций в определенной версии. Дополнительные сведения о подписанных URL-адресах см. в статье об использование подписанных URL-адресов SAS в службе хранилища Azure.
  • С помощью ключей доступа к учетной записи для авторизации операций с версиями BLOB-объектов с общим ключом. Дополнительные сведения см. в статье Авторизация с помощью общего ключа.

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

Действие Azure RBAC для удаления версии BLOB-объекта

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

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

Параметры подписанного URL-адреса (SAS)

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

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

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

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

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

Счета за версии BLOB-объектов, например моментальные снимки BLOB-объектов, выставляются по той же ставке, что и активные данные. Выбор способа оплаты версий зависит от того, был ли явно задан уровень для текущей или предыдущих версий BLOB-объекта (или моментальных снимков). Дополнительные сведения о уровнях BLOB-объектов см. в разделе "Горячий", "Холодный", "Холодный" и "Архив" для данных BLOB-объектов.

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

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

Примечание.

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

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

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

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

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

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

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

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

Сценарий 1

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

Diagram 1 showing billing for unique blocks in base blob and previous version.

Сценарий 2

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

Diagram 2 showing billing for unique blocks in base blob and previous version.

Сценарий 3

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

Diagram 3 showing billing for unique blocks in base blob and previous version.

Сценарий 4

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

Diagram 4 showing billing for unique blocks in base blob and previous version.

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

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

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

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

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

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

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

Diagram showing how objects are billed when a versioned blob is explicitly tiered.

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

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

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

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

Поддерживаемые компоненты

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

Управление версиями не поддерживается для больших двоичных объектов, отправленных с помощью Data Lake Storage 2-го поколения API.

См. также