Управление жизненным циклом хранилища BLOB-объектов AzureManage the Azure Blob storage lifecycle

Для каждого набора данных существуют уникальные требования к жизненному циклу.Data sets have unique lifecycles. На ранних этапах жизненного цикла данных обращение к ним происходит часто.Early in the lifecycle, people access some data often. Но по мере устаревания данных потребность в доступе снижается очень быстро.But the need for access drops drastically as the data ages. Некоторые данные хранятся в облаке почти без использования, и после сохранения к ним обращаются крайне редко.Some data stays idle in the cloud and is rarely accessed once stored. Некоторые данные устаревают через несколько дней или месяцев после их создания, а другие наборы данных активно считываются и изменяются на протяжении всего времени существования.Some data expires days or months after creation, while other data sets are actively read and modified throughout their lifetimes. Управление жизненным циклом хранилища BLOB-объектов Azure предлагает обширную политику на основе правил для учетных записей GPv2 и хранилища BLOB-объектов.Azure Blob storage lifecycle management offers a rich, rule-based policy for GPv2 and Blob storage accounts. Эти политики позволяют переводить данные на новые уровни доступа и удалять их по завершении жизненного цикла.Use the policy to transition your data to the appropriate access tiers or expire at the end of the data's lifecycle.

Политика управления жизненным циклом поддерживает следующие возможности.The lifecycle management policy lets you:

  • Перемещение больших двоичных объектов на более холодный уровень доступа (с горячего на холодный, с горячего на архивный, с холодного на архивный) для оптимального баланса производительности и стоимости.Transition blobs to a cooler storage tier (hot to cool, hot to archive, or cool to archive) to optimize for performance and cost
  • Удаление больших двоичных объектов в конце их жизненных циклов.Delete blobs at the end of their lifecycles
  • Определение правил, выполняемых раз в день, на уровне учетной записи хранения.Define rules to be run once per day at the storage account level
  • Применение правил к контейнерам или подмножеству больших двоичных объектов (с использованием префиксов имен или тегов индекса больших двоичных объектов в качестве фильтров)Apply rules to containers or a subset of blobs (using name prefixes or blob index tags as filters)

Рассмотрим ситуацию, когда данные часто обращаются на ранних стадиях жизненного цикла, но иногда через две недели.Consider a scenario where data gets frequent access during the early stages of the lifecycle, but only occasionally after two weeks. Данные, которые хранятся больше месяца, запрашиваются крайне редко.Beyond the first month, the data set is rarely accessed. В этом сценарии для ранних этапов лучше всего выбрать горячий уровень хранилища.In this scenario, hot storage is best during the early stages. Для случайного доступа наиболее подходящим является наиболее подходящее хранилище.Cool storage is most appropriate for occasional access. Архивное хранилище — это лучший вариант уровня по истечении возраста данных в течение месяца.Archive storage is the best tier option after the data ages over a month. Выбирая уровни хранилища в зависимости от возраста данных, вы сможете создать наиболее экономичный вариант хранилища для конкретных потребностей.By adjusting storage tiers in respect to the age of data, you can design the least expensive storage options for your needs. Чтобы достичь перемещения данных на более холодные уровни, можно использовать правила политики управления жизненным циклом.To achieve this transition, lifecycle management policy rules are available to move aging data to cooler tiers.

Примечание

Функции, описанные в этой статье, теперь доступны для учетных записей с иерархическим пространством имен.The features described in this article are now available to accounts that have a hierarchical namespace. Чтобы просмотреть ограничения, ознакомьтесь с возможностями хранилища BLOB-объектов, доступными в Azure Data Lake Storage 2-го поколения статье.To review limitations, see the Blob storage features available in Azure Data Lake Storage Gen2 article.

Поддержка учетных записей храненияStorage account support

Политика управления жизненным циклом доступна для учетных записей общего назначения v2 (GPv2), учетных записей хранения BLOB-объектов и учетных записей хранения блочных BLOB-объектов уровня "Премиум"The lifecycle management policy is available with General Purpose v2 (GPv2) accounts, Blob storage accounts, and Premium Block Blob storage accounts. В портал Azure можно обновить существующую учетную запись общего назначения (GPv1) до учетной записи GPv2.In the Azure portal, you can upgrade an existing General Purpose (GPv1) account to a GPv2 account. Дополнительные сведения об учетных записях хранения см. в статье Общие сведения об учетной записи хранения.For more information about storage accounts, see Azure storage account overview.

ЦеныPricing

Функция управления жизненным циклом не взимается.The lifecycle management feature is free of charge. Клиенты оплачивают только обычную стоимость вызовов API Отображение BLOB-объектов и Установка уровня BLOB-объектов.Customers are charged the regular operation cost for the List Blobs and Set Blob Tier API calls. Операция удаления бесплатна.Delete operation is free. Дополнительные сведения см. на странице цен на блочные BLOB-объекты.For more information about pricing, see Block Blob pricing.

Доступность по регионамRegional availability

Функция управления жизненным циклом доступна во всех регионах Azure.The lifecycle management feature is available in all Azure regions.

Добавление или удаление политикиAdd or remove a policy

Добавить, изменить или удалить политику можно с помощью любого из следующих методов.You can add, edit, or remove a policy by using any of the following methods:

Политику можно прочитать или записать полностью.A policy can be read or written in full. Частичные обновления не поддерживаются.Partial updates are not supported.

Примечание

Если вы настроили для учетной записи хранения правила брандмауэра, запросы на управление жизненным циклом могут быть заблокированы.If you enable firewall rules for your storage account, lifecycle management requests may be blocked. Вы можете разблокировать эти запросы, предоставив исключения для доверенных служб Майкрософт.You can unblock these requests by providing exceptions for trusted Microsoft services. Дополнительные сведения см. в разделе об исключениях в статье Настройка брандмауэров службы хранилища Azure и виртуальных сетей.For more information, see the Exceptions section in Configure firewalls and virtual networks.

В этой статье показано, как управлять политикой с помощью портала и методов PowerShell.This article shows how to manage policy by using the portal and PowerShell methods.

Существует два способа добавления политики с помощью портал Azure.There are two ways to add a policy through the Azure portal.

Представление списка портал AzureAzure portal List view

  1. Войдите на портал Azure.Sign in to the Azure portal.

  2. В портал Azure найдите и выберите свою учетную запись хранения.In the Azure portal, search for and select your storage account.

  3. В разделе Служба BLOB-объектоввыберите Управление жизненным циклом , чтобы просмотреть или изменить правила.Under Blob Service, select Lifecycle management to view or change your rules.

  4. Перейдите на вкладку представление списка .Select the List view tab.

  5. Выберите Добавить правило , а затем заполните поля формы набор действий .Select Add rule and then fill out the Action set form fields. В следующем примере большие двоичные объекты перемещаются в очень удобном хранилище, если они не были изменены в течение 30 дней.In the following example, blobs are moved to cool storage if they haven't been modified for 30 days.

    Страница набора действий по управлению жизненным циклом в портал Azure

  6. Выберите фильтр установить , чтобы добавить необязательный фильтр.Select Filter set to add an optional filter. Затем нажмите кнопку Обзор , чтобы указать контейнер и папку для фильтрации.Then, select Browse to specify a container and folder by which to filter.

    Страница "набор фильтров управления жизненным циклом" в портал Azure

  7. Выберите проверить и добавить , чтобы проверить параметры политики.Select Review + add to review the policy settings.

  8. Нажмите кнопку Добавить , чтобы добавить новую политику.Select Add to add the new policy.

Представление кода портал AzureAzure portal Code view

  1. Войдите на портал Azure.Sign in to the Azure portal.

  2. В портал Azure найдите и выберите свою учетную запись хранения.In the Azure portal, search for and select your storage account.

  3. В разделе Служба BLOB-объектоввыберите Управление жизненным циклом , чтобы просмотреть или изменить политику.Under Blob Service, select Lifecycle management to view or change your policy.

  4. Следующий JSON является примером политики, которую можно вставлять на вкладку представление кода .The following JSON is an example of a policy that can be pasted into the Code view tab.

    {
      "rules": [
        {
          "name": "ruleFoo",
          "enabled": true,
          "type": "Lifecycle",
          "definition": {
            "filters": {
              "blobTypes": [ "blockBlob" ],
              "prefixMatch": [ "container1/foo" ]
            },
            "actions": {
              "baseBlob": {
                "tierToCool": { "daysAfterModificationGreaterThan": 30 },
                "tierToArchive": { "daysAfterModificationGreaterThan": 90 },
                "delete": { "daysAfterModificationGreaterThan": 2555 }
              },
              "snapshot": {
                "delete": { "daysAfterCreationGreaterThan": 90 }
              }
            }
          }
        }
      ]
    }
    
  5. Нажмите кнопку Сохранить.Select Save.

  6. Дополнительные сведения об этом примере JSON см. в разделах Политика и правила .For more information about this JSON example, see the Policy and Rules sections.

ПолитикаPolicy

Политика управления жизненным циклом представляет собой набор правил, оформленный в виде документа JSON.A lifecycle management policy is a collection of rules in a JSON document:

{
  "rules": [
    {
      "name": "rule1",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {...}
    },
    {
      "name": "rule2",
      "type": "Lifecycle",
      "definition": {...}
    }
  ]
}

Политика — это набор правил.A policy is a collection of rules:

Имя параметраParameter name Тип параметраParameter type ПримечанияNotes
rules Массив объектов правилAn array of rule objects В политике требуется по крайней мере одно правило.At least one rule is required in a policy. В политике можно определить до 100 правил.You can define up to 100 rules in a policy.

Каждое правило в политике имеет несколько параметров:Each rule within the policy has several parameters:

Имя параметраParameter name Тип параметраParameter type ПримечанияNotes Обязательное значениеRequired
name СтрокаString Имя правила может включать до 256 буквенно-цифровых символов.A rule name can include up to 256 alphanumeric characters. В именах правил учитывается регистр.Rule name is case-sensitive. Имя должно быть уникальным в пределах политики.It must be unique within a policy. TrueTrue
enabled ЛогическоеBoolean Необязательное логическое значение, которое позволяет временно отключить правило.An optional boolean to allow a rule to be temporary disabled. Значение по умолчанию — true, если оно не задано.Default value is true if it's not set. FalseFalse
type Значение перечисленияAn enum value Текущий допустимый тип — Lifecycle .The current valid type is Lifecycle. TrueTrue
definition Объект, который определяет правило жизненного циклаAn object that defines the lifecycle rule Каждое определение состоит из набора фильтров и набора действий.Each definition is made up of a filter set and an action set. TrueTrue

ПравилаRules

Каждое определение правила состоит из набора фильтров и набора действий.Each rule definition includes a filter set and an action set. Набор фильтров ограничивает действие правила определенным набором объектов в контейнере или имен объектов.The filter set limits rule actions to a certain set of objects within a container or objects names. Набор операций вводит в действие уровень или удаляет действия в отфильтрованном наборе объектов.The action set applies the tier or delete actions to the filtered set of objects.

Пример правилаSample rule

В следующем примере правила выполняется фильтрация учетной записи для выполнения действий с объектами, которые существуют внутри container1 и начинаются с foo .The following sample rule filters the account to run the actions on objects that exist inside container1 and start with foo.

Примечание

Управление жизненным циклом поддерживает только тип блочного BLOB-объекта.Lifecycle management only supports block blob type.

  • установить для BLOB-объекта холодный уровень доступа через 30 дней после последнего изменения;Tier blob to cool tier 30 days after last modification
  • установить для BLOB-объекта архивный уровень доступа через 90 дней после последнего изменения;Tier blob to archive tier 90 days after last modification
  • удалить BLOB-объект спустя 2555 дней (7 лет) после последнего изменения;Delete blob 2,555 days (seven years) after last modification
  • удалить моментальный снимок BLOB-объекта через 90 дней после создания моментального снимка.Delete blob snapshots 90 days after snapshot creation
{
  "rules": [
    {
      "name": "ruleFoo",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "container1/foo" ]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 90 },
            "delete": { "daysAfterModificationGreaterThan": 2555 }
          },
          "snapshot": {
            "delete": { "daysAfterCreationGreaterThan": 90 }
          }
        }
      }
    }
  ]
}

Фильтры правилаRule filters

Фильтры ограничивают действие правила определенным подмножеством BLOB-объектов в учетной записи хранения.Filters limit rule actions to a subset of blobs within the storage account. Если определено несколько фильтров, для всех фильтров применяется логическая операция AND.If more than one filter is defined, a logical AND runs on all filters.

Доступны следующие фильтры:Filters include:

Имя фильтраFilter name Тип фильтраFilter type ПримечанияNotes ОбязательныйIs Required
blobTypesblobTypes Массив предустановленных значений перечисления.An array of predefined enum values. Текущий выпуск поддерживает blockBlob .The current release supports blockBlob. ДаYes
prefixMatchprefixMatch Массив строк для сопоставления префиксов.An array of strings for prefixes to be matched. Каждое правило может определять до 10 префиксов.Each rule can define up to 10 prefixes. Строка префикса должно начинаться с имени контейнера.A prefix string must start with a container name. Например, если нужно сопоставить все большие двоичные объекты в https://myaccount.blob.core.windows.net/container1/foo/... правиле, префиксматч имеет значение container1/foo .For example, if you want to match all blobs under https://myaccount.blob.core.windows.net/container1/foo/... for a rule, the prefixMatch is container1/foo. Если не определить Префиксматч, правило применяется ко всем BLOB-объектам в учетной записи хранения.If you don't define prefixMatch, the rule applies to all blobs within the storage account. НетNo
блобиндексматчblobIndexMatch Массив значений словаря, состоящий из ключа тега индекса больших двоичных объектов и условий значения для сопоставления.An array of dictionary values consisting of Blob Index tag key and value conditions to be matched. Каждое правило может определять до 10 условий тега индекса больших двоичных объектов.Each rule can define up to 10 Blob Index tag condition. Например, если вы хотите сопоставить все большие двоичные объекты Project = Contoso с https://myaccount.blob.core.windows.net/ для правила, блобиндексматч имеет значение {"name": "Project","op": "==","value": "Contoso"} .For example, if you want to match all blobs with Project = Contoso under https://myaccount.blob.core.windows.net/ for a rule, the blobIndexMatch is {"name": "Project","op": "==","value": "Contoso"}. Если не определить Блобиндексматч, правило применяется ко всем BLOB-объектам в учетной записи хранения.If you don't define blobIndexMatch, the rule applies to all blobs within the storage account. НетNo

Примечание

Индекс больших двоичных объектов находится в стадии общедоступной предварительной версии и доступен в регионах Центральная Франция и Южная Франция.Blob Index is in public preview, and is available in the France Central and France South regions. Дополнительные сведения об этой функции, а также известных проблемах и ограничениях см. в статье Управление данными в хранилище BLOB-объектов Azure и их поиск с помощью индекса больших двоичных объектов (предварительная версия).To learn more about this feature along with known issues and limitations, see Manage and find data on Azure Blob Storage with Blob Index (Preview).

Действия правилаRule actions

Действия применяются к отфильтрованным BLOB-объектам при выполнении условия выполнения.Actions are applied to the filtered blobs when the run condition is met.

Управление жизненным циклом поддерживает распределение и удаление больших двоичных объектов и удаление моментальных снимков больших двоичных объектов.Lifecycle management supports tiering and deletion of blobs and deletion of blob snapshots. Определите в каждом правиле хотя бы одно действие для BLOB-объектов или моментальных снимков BLOB-объектов.Define at least one action for each rule on blobs or blob snapshots.

ДействиеAction Базовый BLOB-объектBase Blob СнимокSnapshot
tierToCooltierToCool Поддержка BLOB-объектов, размещенных на горячем уровне доступаSupport blobs currently at hot tier Не поддерживаетсяNot supported
tierToArchivetierToArchive Поддержка BLOB-объектов, размещенных на горячем или холодном уровне доступаSupport blobs currently at hot or cool tier Не поддерживаетсяNot supported
удалитьdelete ПоддерживаетсяSupported ПоддерживаетсяSupported

Примечание

Если для одного BLOB-объекта определено более одного действия, управление жизненным циклом применяет к нему более дешевое из этих действий.If you define more than one action on the same blob, lifecycle management applies the least expensive action to the blob. Например, действие delete дешевле, чем действие tierToArchive;For example, action delete is cheaper than action tierToArchive. а действие tierToArchive дешевле, чем действие tierToCool.Action tierToArchive is cheaper than action tierToCool.

Условия выполнения основаны на возраст.The run conditions are based on age. Возраст для базового BLOB-объекта определяется по времени последнего изменения, а для моментального снимка BLOB-объекта — по времени создания.Base blobs use the last modified time to track age, and blob snapshots use the snapshot creation time to track age.

Условие выполнения действияAction run condition Значение условияCondition value Описание:Description
daysAfterModificationGreaterThandaysAfterModificationGreaterThan Целочисленное значение, указывающее возраст в дняхInteger value indicating the age in days Условие для действий базового большого двоичного объектаThe condition for base blob actions
daysAfterCreationGreaterThandaysAfterCreationGreaterThan Целочисленное значение, указывающее возраст в дняхInteger value indicating the age in days Условие для действий моментальных снимков BLOB-объектовThe condition for blob snapshot actions

ПримерыExamples

Следующие примеры демонстрируют несколько типичных сценариев для правил политики жизненного цикла.The following examples demonstrate how to address common scenarios with lifecycle policy rules.

Перемещение старых данных на более холодный уровеньMove aging data to a cooler tier

В следующем примере показано перемещение блочных BLOB-объектов с префиксом имени container1/foo или container2/bar.This example shows how to transition block blobs prefixed with container1/foo or container2/bar. Эта политика перемещает BLOB-объекты, которые не изменялись более 30 дней, на холодный уровень, а которые не изменялись в течение 90 дней — на архивный уровень:The policy transitions blobs that haven't been modified in over 30 days to cool storage, and blobs not modified in 90 days to the archive tier:

{
  "rules": [
    {
      "name": "agingRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "container1/foo", "container2/bar" ]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 90 }
          }
        }
      }
    }
  ]
}

Архивировать данные после приемаArchive data after ingest

Некоторые данные хранятся в облаке почти без использования.Some data stays idle in the cloud and is rarely, if ever, accessed once stored. Следующая политика жизненного цикла настроена для архивации данных вскоре после приема.The following lifecycle policy is configured to archive data shortly after it is ingested. В этом примере выполняется перевод блочных BLOB-объектов в учетной записи хранения в контейнере archivecontainer в архивный уровень.This example transitions block blobs in the storage account within container archivecontainer into an archive tier. Переход выполняется с помощью больших двоичных объектов за 0 дней после последнего изменения:The transition is accomplished by acting on blobs 0 days after last modified time:

Примечание

Рекомендуется передать большие двоичные объекты непосредственно на уровне архива, чтобы повысить эффективность.It is recommended to upload your blobs directly the archive tier to be more efficient. Вы можете использовать заголовок x-MS-Access-уровня для PutBlob или PutBlockList с оставшейся версией 2018-11-09 и более поздней или нашей последней клиентской библиотекой хранилища BLOB-объектов.You can use the x-ms-access-tier header for PutBlob or PutBlockList with REST version 2018-11-09 and newer or our latest blob storage client libraries.

{
  "rules": [
    {
      "name": "archiveRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "archivecontainer" ]
        },
        "actions": {
          "baseBlob": {
              "tierToArchive": { "daysAfterModificationGreaterThan": 0 }
          }
        }
      }
    }
  ]
}

Устаревание данных на основе возрастаExpire data based on age

Ожидается, что срок действия некоторых данных истекает в днях или месяцах после создания.Some data is expected to expire days or months after creation. Вы можете настроить политику управления жизненным циклом, чтобы удалять устаревшие данные при достижении определенного возраста.You can configure a lifecycle management policy to expire data by deletion based on data age. В следующем примере показана политика, которая удаляет все блочные BLOB-объекты старше 365 дней.The following example shows a policy that deletes all block blobs older than 365 days.

{
  "rules": [
    {
      "name": "expirationRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ]
        },
        "actions": {
          "baseBlob": {
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        }
      }
    }
  ]
}

Удаление данных с помощью тегов индекса больших двоичных объектовDelete data with Blob Index tags

Некоторые данные должны быть просрочены только в том случае, если они явно помечены для удаления.Some data should only be expired if explicitly marked for deletion. Политику управления жизненным циклом можно настроить для истечения срока действия данных, помеченных атрибутами ключ/значение индекса больших двоичных объектов.You can configure a lifecycle management policy to expire data that are tagged with blob index key/value attributes. В следующем примере показана политика, которая удаляет все блочные BLOB-объекты, помеченные Project = Contoso .The following example shows a policy that deletes all block blobs tagged with Project = Contoso. Дополнительные сведения об индексе больших двоичных объектов см. в статье Управление данными в хранилище BLOB-объектов Azure и их поиск с помощью индекса больших двоичных объектов (предварительная версия).To learn more about the Blob Index, see Manage and find data on Azure Blob Storage with Blob Index (Preview).

{
    "rules": [
        {
            "enabled": true,
            "name": "DeleteContosoData",
            "type": "Lifecycle",
            "definition": {
                "actions": {
                    "baseBlob": {
                        "delete": {
                            "daysAfterModificationGreaterThan": 0
                        }
                    }
                },
                "filters": {
                    "blobIndexMatch": [
                        {
                            "name": "Project",
                            "op": "==",
                            "value": "Contoso"
                        }
                    ],
                    "blobTypes": [
                        "blockBlob"
                    ]
                }
            }
        }
    ]
}

Удаление старых моментальных снимковDelete old snapshots

Для данных, которые часто изменяются и используются на протяжении их существования, часто используются моментальные снимки для отслеживания ранних версий данных.For data that is modified and accessed regularly throughout its lifetime, snapshots are often used to track older versions of the data. Вы можете создать политику, которая удаляет старые моментальные снимки при достижении определенного возраста.You can create a policy that deletes old snapshots based on snapshot age. Возраст моментального снимка определяется от момента создания моментального снимка.The snapshot age is determined by evaluating the snapshot creation time. Это правило политики удаляет моментальные снимки BLOB-объектов в пределах контейнера activedata, с момента создания которых прошло 90 или более дней.This policy rule deletes block blob snapshots within container activedata that are 90 days or older after snapshot creation.

{
  "rules": [
    {
      "name": "snapshotRule",
      "enabled": true,
      "type": "Lifecycle",
    "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "activedata" ]
        },
        "actions": {
          "snapshot": {
            "delete": { "daysAfterCreationGreaterThan": 90 }
          }
        }
      }
    }
  ]
}

ВОПРОСЫ И ОТВЕТЫFAQ

Я создал новую политику, почему действия не выполняются немедленно?I created a new policy, why do the actions not run immediately?
Платформа выполняет политики жизненного цикла один раз в день.The platform runs the lifecycle policy once a day. После настройки политики для первого выполнения некоторых действий может потребоваться до 24 часов.Once you configure a policy, it can take up to 24 hours for some actions to run for the first time.

Сколько времени требуется для выполнения действий при обновлении существующей политики?If I update an existing policy, how long does it take for the actions to run?
Обновленная политика вступает в силу до 24 часов.The updated policy takes up to 24 hours to go into effect. Когда политика вступит в силу, выполнение действий может занять до 24 часов.Once the policy is in effect, it could take up to 24 hours for the actions to run. Поэтому выполнение действий политики может занять до 48 часов.Therefore, the policy actions may take up to 48 hours to complete.

Я вручную повторно занесли в архив большой двоичный объект, как предотвратить его временное перемещение на архивный уровень?I manually rehydrated an archived blob, how do I prevent it from being moved back to the Archive tier temporarily?
При перемещении большого двоичного объекта с одного уровня доступа на другой его время последнего изменения не изменяется.When a blob is moved from one access tier to another, its last modification time doesn't change. Если вы вручную восстанавливаете архивный BLOB-объект на "горячем" уровне, он перемещается обратно на уровень архива с помощью подсистемы управления жизненным циклом.If you manually rehydrate an archived blob to hot tier, it would be moved back to archive tier by the lifecycle management engine. Отключите правило, которое временно влияет на этот большой двоичный объект, чтобы предотвратить его архивацию.Disable the rule that affects this blob temporarily to prevent it from being archived again. Повторно включите правило, когда большой двоичный объект можно безопасно переместить обратно на архивный уровень.Re-enable the rule when the blob can be safely moved back to archive tier. Вы также можете скопировать большой двоичный объект в другое расположение, если он должен постоянно оставаться на активном или холодном уровне.You may also copy the blob to another location if it needs to stay in hot or cool tier permanently.

Дальнейшие шагиNext steps

Узнайте, как восстанавливать данные после случайного удаления:Learn how to recover data after accidental deletion:

Узнайте, как управлять данными и находить их с помощью индекса больших двоичных объектов:Learn how to manage and find data with Blob Index: