blob storage

Organize Blob and Object Storage Without File Search

Jul 20, 2026

Object Storage Is Not a Digital Asset Manager

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.

The Blober Model

An organization workflow has four layers:

Browse and select a scope. Choose a bucket area, folder-like prefix, several folders, or specific files.
Filter the scope. Restrict by extension, creation age, size, recursive inclusion, or glob rules.
Choose a destination. Use another provider, bucket, container, account, local disk, NAS, or supported non-overlapping folder.
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.

What This Can and Cannot Search

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.

Example: Recover a Flat Media Bucket

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.

Example: Extract Business Records

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.

Example: Split Active and Archive Storage

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.

Reorganizing on the Same Provider

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.

Why Not Build an Index First?

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.

Make the Destination Easier to Search Next Time

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.

Safe Rollout

Choose one painful prefix rather than the whole bucket.
Use Copy.
Add the smallest useful include/exclude rule.
Add a path template only if the preserved structure is insufficient.
Review Preview & Summary.
Run and verify object counts and samples.
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.