Is there no way to automatically archive blobs that are in the Cool storage tier without having to move them?

JohnSebastian-3934 606 Reputation points
2026-10-22T19:07:15.23+00:00

We have over 78TB of Blobs that were for a project that is now completed. This 78TB contains hundreds of millions of blobs. We now want to archive these blobs. Is there no way to do this automatically without having to move blobs to another storage account that is set to the archive tier? One would think that Microsoft Engineers would think of this given that Azure storage is capable of storing PEtabytes of data and many customers are going to want to archive data after a period of time. Forcing the customer to have to move the data is error prone and lazy on behalf of Microsoft engineers.

Azure Blob Storage
Azure Blob Storage

An Azure service that stores unstructured data in the cloud as blobs.


Answer accepted by question author

AI answer

2026-10-22T19:08:19.7566667+00:00

Use an Azure Blob Storage lifecycle-management policy to change the existing blobs from Cool to Archive in the same storage account; no copy or move to another account is required.^1^

Configure the policy

In the Azure portal:

  1. Open the Storage account containing the blobs.
  2. Select Data management → Lifecycle management.
  3. Select Add a rule.
  4. On Details:
    • Enter a rule name.
    • Select Limit blobs with filters if the account contains data that must not be archived.
    • Select Block blobs.
  5. On Base blobs:
    • Choose Last modified or Created.
    • Select Move to archive storage.
    • Enter the required age. For a completed project whose blobs already exceed that age, they become eligible during policy processing.
  6. On Filter set, specify the project’s container or path prefix.
    • A prefix must begin with the container name.
    • For example, completed-project/data/.
    • Prefixes are case-sensitive and do not support wildcards.
  7. Select Add.^2^

For example, this policy archives eligible block blobs under one container after they have remained unmodified for more than zero days:

{
  "rules": [{
    "name": "archive-completed-project",
    "enabled": true,
    "type": "Lifecycle",
    "definition": {
      "filters": {
        "blobTypes": ["blockBlob"],
        "prefixMatch": ["completed-project/"]
      },
      "actions": {
        "baseBlob": {
          "tierToArchive": {
            "daysAfterModificationGreaterThan": 0
          }
        }
      }
    }
  }]
}

This documented pattern uses tierToArchive and changes the blob tier after ingestion without relocating the blob.^3^

Important checks before enabling it

Archive-in-place is supported only when all relevant conditions are met:

  • The objects are block blobs, not append or page blobs.
  • The account is not a premium block blob account.
  • The account redundancy is LRS, GRS, or RA-GRS. Archive is not supported with ZRS, GZRS, or RA-GZRS.
  • The blobs do not use an encryption scope, which prevents lifecycle tiering to Archive.^4^

If these conditions are not met, changing accounts or copying data may be necessary. Otherwise, no second storage account is needed.

Expectations for hundreds of millions of blobs

Policy changes can take up to 24 hours to take effect and begin their first execution. Completion time depends on the number of blobs and the storage account’s request rate, so hundreds of millions of blobs will not necessarily transition in a single day. Lifecycle policies themselves have no charge, but each tier change incurs the standard Set Blob Tier operation cost.^1^

Also account for the following:

  • Moving Cool blobs to Archive is a tier change, not a data transfer to another account.
  • Cool blobs moved before completing Cool’s 30-day minimum retention can incur a prorated early-deletion charge.
  • Archived blobs should remain archived for at least 180 days to avoid Archive early-deletion charges.
  • Archive is offline: reading or modifying a blob requires rehydration, potentially taking hours and incurring retrieval charges.^5^

If the rule appears not to match data, first inspect the prefix: it must include the container name and match the blob-name casing exactly.


References

  1. Azure Blob Storage lifecycle management overview
  2. Configure a lifecycle management policy
  3. Lifecycle management policies that transition blobs between tiers
  4. Azure Blob Storage lifecycle management policy structure
  5. Access tiers for blob data
AI-generated content may be incorrect. Read our transparency notes for more information.

Was this answer helpful?

1 person found this answer helpful.

2 additional answers

Sort by: Most helpful
  1. Alex Burlachenko 26,275 Reputation points MVP Volunteer Moderator
    2026-10-23T14:52:20.9333333+00:00

    Hi JohnSebastian-3934 & thx for join me at Q&A platform,

    Actually, Azure Blob Storage already supports exactly this through Lifecycle Management policies. You don't need to copy 78 TB of data to another storage account or write a script to move hundreds of millions of blobs individually.

    You can change existing blobs directly from Cool to Archive within the same storage account, keeping their original names and paths. Azure handles the tier transition through its Set Blob Tier operation, without requiring you to download and upload the data again.

    In the Azure portal, open your storage account, go to Data management > Lifecycle management, and create a rule that transitions block blobs to Archive based on their age.

    For example, you can configure tierToArchive with daysAfterModificationGreaterThan: 0 to archive eligible blobs that haven't been modified for more than zero days. You can limit the rule to specific containers or blob prefixes so it doesn't affect unrelated data.

    One thing to clarify: lifecycle rules are based on conditions such as blob age, prefixes, and tags. They aren't simply a switch that says "archive everything currently in Cool." So if you have other tiers mixed into the same scope, make sure the rule won't archive data you still need online.

    For your volume, the main concern is the number of objects, not just the 78 TB of data. Lifecycle Management runs automatically, but processing hundreds of millions of blobs won't necessarily finish in one day. Azure may need multiple policy runs, and each tier change has an associated transaction cost.

    Before enabling it across the entire dataset, I'd test the policy against a small container and estimate the total tier-change transaction charges. With hundreds of millions of relatively small blobs, those charges can be significant.

    Make sure the storage account supports Archive. It's supported for standard block blobs with LRS, GRS, or RA-GRS redundancy, but not ZRS, GZRS, or RA-GZRS. There are additional restrictions for certain blob configurations, including encryption scopes. And remember that archived blobs are offline. They must be rehydrated before being read, which can take hours, and Archive has a 180-day minimum retention period for billing purposes.

    So no separate storage account is required, provided your existing account supports Archive. For this scale, I'd definitely use a lifecycle policy rather than manually processing individual blobs. what redundancy type is your current storage account using: LRS, GRS, ZRS, or GZRS? That's the first thing I'd verify, bc it determines whether you can archive the blobs in place.

    rgds,

    Alex

    p.s. if my answer is help - pls mark it as an answer

    Was this answer helpful?

    0 comments No comments

  2. JohnSebastian-3934 606 Reputation points
    2026-10-22T20:48:00.2366667+00:00

    GZRS redundancy and ZRS redundancy storage accounts are not compatible with archive mode. A simple message on the Azure Portal would have provided answers to this and avoided wasting several hours of my time that I will never get back.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.