blob storage

The Azure portal is fine when you need to inspect one container. It is a poor way to answer account-wide questions such as:

• How much data is in Hot, Cool, Cold, and Archive?
• Which old blobs are still on Hot?
• Which objects have a legal hold or encryption status?
• How large are the current versions, snapshots, and previous versions?

Azure Blob Inventory is the native reporting feature for that job. It writes a scheduled CSV or Apache Parquet report into a container in the storage account.^[1]

An inventory policy controls the fields and records in the report. Microsoft documents fields including:

• Name and blob type
• Creation and last-modified time
• Last access time
• Content length and content type
• ETag and content MD5
• Access tier and tier-change time
• Lease status
• Server-encryption status
• Metadata

The policy can include current blobs, snapshots, versions, and deleted records. Filters can narrow the report by blob type, age, and path prefix.

This is more reliable than scraping rows from the portal because Azure generates the report from a declared policy.

Blob Inventory runs daily or weekly. It is not a live query button.

Create the destination container before enabling the policy, choose the fields you need, and wait for the scheduled report. Microsoft does not promise one fixed delivery hour, so do not build a same-minute operational process around it.

If you need to browse and act on files now, use the portal, CLI, SDK, or a file browser. Inventory is better for repeatable audits and trend analysis.

An inventory policy can contain up to 100 rules. More rules are not automatically better.

Begin with one report for current block blobs and include only the fields needed for the first question. CSV is easy to inspect. Parquet is a better fit when an analytics tool will process a large report.

After the first output arrives:

1. Confirm that the expected containers and prefixes appear.
2. Check the tier values against a few known blobs.
3. Compare the total content length with an independent account estimate.
4. Add snapshots, versions, or deleted records only if the audit needs them.

Use Blob Inventory when you need a scheduled account report. Use Blober when you need to browse selected containers, filter records, preview a transfer, change tiers, or reorganize files now.

The two tools fit together. Inventory finds a population, such as old Hot blobs. Blober can then handle a selected operational move or tier change without turning the reporting policy into a transfer script.

• How to Bulk Change Azure Blob Storage Access Tiers
• Azure Blob Tiers vs S3 Storage Classes
• Organize Blob and Object Storage Without File Search
• Azure Blob Storage Setup and Transfers

Inventory tells you what is there. Blober lets you browse, filter, and act on it. Select blobs, change access tiers, and move data between Azure and other providers from a desktop app.

Download Blober at blober.io

An Azure blob in Archive cannot be read or modified. Changing a label in the portal does not make it instantly available. Azure has to rehydrate the data into an online tier.^[1]

There are two methods:

1. Change the existing blob's tier with Set Blob Tier.
2. Copy the archived blob into a new blob on Hot, Cool, or Cold.

The right method depends on retention rules, versions, lifecycle policies, and whether the original archived object must remain untouched.

Standard priority processes requests in the order Azure receives them. Microsoft says objects under 10 GB may take up to 15 hours.

High priority costs more and may complete in under one hour for objects under 10 GB. You can raise an active request from Standard to High, but you cannot lower it again.

Those times are not a promise for a whole account. Rehydration throughput is limited at the storage-account level, not granted independently to every blob. A large batch can take much longer than the small-object estimate.

Microsoft recommends batching rehydration requests. That makes progress easier to observe and reduces the chance that account-level throughput turns one emergency restore into a queue of thousands of competing objects.

Start with the files needed first. Confirm that they reach the online tier and can be read before requesting the rest.

Snapshots and previous blob versions cannot be rehydrated in place. Copy them into a new online blob.

This matters during a recovery. The version you need may not be the current object. Check version and snapshot identifiers before assuming that Set Blob Tier will recover it.

Changing the same archived blob to an online tier before the Archive minimum duration ends can create an early deletion charge. Copying it into a new online blob leaves the archived source in place and can avoid that specific fee.

A copy can also protect against an old lifecycle rule. Rehydrating the same blob does not necessarily make its last-modified date new. A policy based on age may move it back to Archive. A new copy has a new object history that is easier to reason about.

Check current Azure prices before choosing a method. Storage, retrieval, read operations, high-priority rehydration, and early deletion can all affect the bill.^[2]

Blober can apply a tier change to selected Azure blobs without a PowerShell loop. Azure still controls the rehydration queue and timing.

For a recovery, select a small batch, request the destination tier, wait for Azure to complete it, and open representative files. A status change is useful. A readable file is the real test.

• How to Bulk Change Azure Blob Storage Access Tiers
• Azure Blob Tiers vs S3 Storage Classes
• Cloud Storage Ingress vs Egress Fees Explained
• Azure Blob Storage Setup and Transfers

Blober applies tier changes to the blobs you select, without a PowerShell loop. Azure still controls the rehydration queue, so plan the wait and verify the files afterwards.

Download Blober at blober.io

S3-compatible object storage and Azure Blob Storage are excellent at durable, scalable storage. Their basic model is intentionally simple: a bucket or container holds objects identified by keys.

That model creates a familiar pain. The data is safe, but finding a useful subset can be difficult.

A typical bucket may contain:

• Camera originals and edited exports
• Client deliverables and internal drafts
• Application uploads with generated names
• Logs, reports, backups, and temporary artifacts
• Years of prefixes created by different teams

Provider consoles commonly support listing by prefix and basic properties. They are not necessarily designed for visual multi-folder selection, reusable include/exclude rules, or reorganizing objects into a new human structure.

Blober does not turn object storage into full-text or AI search. It solves a narrower, practical problem: identify files from paths and metadata, then copy or move them into a better layout.

An organization workflow has four layers:

1. Browse and select a scope. Choose a bucket area, folder-like prefix, several folders, or specific files.
2. Filter the scope. Restrict by extension, creation age, size, recursive inclusion, or glob rules.
3. Choose a destination. Use another provider, bucket, container, account, local disk, NAS, or supported non-overlapping folder.
4. Build paths. Preserve the hierarchy or create a custom destination with metadata variables.

The source provider does not need a native integration with the destination provider. Blober connects to both endpoints locally.

Blober can target:

• Paths and filenames
• File extensions
• Source-reported created date
• Source-reported file size
• Folder depth through recursive selection
• Include and exclude glob patterns

Blober path workflows do not provide:

• OCR inside scanned documents
• Full-text search inside PDFs
• Face, object, or scene recognition
• Speech transcription
• Semantic search such as "all beach videos"

That boundary matters. If filenames and paths contain useful conventions, Blober can act on them immediately. If the only useful information exists inside file contents, a dedicated indexing system is still required.

Suppose a bucket contains:

uploads/GX015742.MP4
uploads/GOPR0001.JPG
uploads/DSC_4821.ARW
uploads/contract.pdf
uploads/proxies/GX015742-low.mp4

Select uploads, then configure:

Include: **/*.{mp4,mov,jpg,jpeg,arw,dng}
Exclude: **/proxies/**
Template: media/{file_ext}/{file_created_date}/{filename}

The destination becomes browseable by extension and source-reported creation date. The source can remain unchanged if the action is Copy.

A company bucket mixes customer uploads, generated reports, and temporary processing artifacts.

Selected prefix: production
Include: **/*.{pdf,csv,xlsx,json}
Exclude: **/{tmp,temp,cache,failed}/**
Template: records/{file_modified_date}/{file_dir}/{filename}

This creates a separate records archive while retaining relative source context.

Large inactive files can remain expensive in active storage.

Create a workflow that:

• Selects completed project prefixes
• Filters to large files
• Excludes current working or proxy folders
• Copies to a lower-cost archive provider
• Preserves {file_dir}/{filename}

Verify the archive before considering a move or source cleanup.

Where the adapter supports the selected source and destination action, Blober can copy or move between separate locations on the same provider.

The destination cannot be the same as the source or nested inside a selected source folder. That overlap could make the scan loop over its own output or overwrite files. Choose a sibling prefix, separate bucket/container, or separate account.

For example:

Source: messy-imports
Destination: organized-archive
Template: {file_ext}/{file_created_date}/{file_dir}/{filename}

Copy first. Compare counts and sample files. Move only when deleting the source is intentional.

A search index is appropriate when users need ongoing content discovery. It also introduces ingestion, synchronization, schemas, permissions, infrastructure, and recurring cost.

Blober is useful when the immediate pain is operational:

• "Copy every final MP4 but not proxies."
• "Move PDFs older than the working set into an archive."
• "Separate RAW files from exports."
• "Preserve every project subfolder while changing the top-level layout."
• "Collect large files into cheaper storage."

Those are transfer-and-path problems. They do not need a permanent search service.

Organization during transfer can encode the metadata users actually browse:

archive/{file_ext}/{file_created_date}/{file_dir}/{filename}

The destination now supports useful prefix browsing:

• Start at type
• Narrow to a date
• Retain project hierarchy
• End at the original filename

This is not semantic search, but it converts an opaque dump into predictable paths using information already available.

1. Choose one painful prefix rather than the whole bucket.
2. Use Copy.
3. Add the smallest useful include/exclude rule.
4. Add a path template only if the preserved structure is insufficient.
5. Review Preview & Summary.
6. Run and verify object counts and samples.
7. Expand the selection after the rule proves itself.

See selection and glob filters for pattern details and the complete path-template guide for destination behavior.