# Organize Blob and Object Storage Without File Search

> Turn S3 buckets and Azure Blob containers into usable archives with Blober selection, glob filters, transfer workflows, and destination paths.

## 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:

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.

## 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:

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

Select `uploads`, then configure:

```text
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.

```text
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:

```text
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:

```text
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

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](/kb/articles/blober-file-selection-glob-filters/) for pattern details and the [complete path-template guide](/kb/articles/blober-path-templates-complete-guide/) for destination behavior.