Cold Storage Rehydrate

4 min read

Burrow keeps recent audit data on disk for fast Forage searching. Older data is automatically moved to your Azure Blob cold-storage container after about 14 days. To search those older months in Forage, you first rehydrate them — bring the cold data back into a local cache for query.

This article covers when to rehydrate, how to rehydrate, and what to do if a job gets stuck.

When to rehydrate

You need to rehydrate when:

The Forage date range you're searching extends earlier than the on-disk retention window.
An auditor or HR question covers months that haven't been searched recently.
You're building a Rule replay against a rule change to see what would have fired over a historical window.

You do not need to rehydrate for normal recent-activity searches — Burrow keeps roughly the last 14 days on disk by default, queryable directly.

The Cold Storage panel

Open the Forage page. The Cold Storage panel sits at the top, collapsed by default. Expand it.

The header shows manifest stats — total entities in cold storage, the month range available, total bytes, last manifest refresh.

Below the header:

Entity input — optional. Leave blank to rehydrate every entity for the month range (uses more storage bandwidth and a larger cache). Fill in to rehydrate just one user.
From month / To month — YYYYMM format. Leave blank for all available months.
Rehydrate — submit the job.

Below the controls, two job lists:

Active and recent jobs (this session) — jobs you've submitted in the current dashboard session.
All jobs on disk — every rehydrate that's left a cache on the server, with state, age, and a delete button.

A worked example: rehydrate a quarter of one user's activity

An auditor asks: "What did Shane do between March and May?" You're querying that in late June, so March, April, and May are all in cold storage.

Open the Forage page → expand the Cold Storage panel.
Enter Entity shane.quinnell@example.com.
Enter From month 202603, To month 202605.
Click Rehydrate.
A new job row appears in "Active and recent jobs" with state queued. Within seconds it flips to fetching and a percentage progress fills in.
Wait for state to flip to ready. Typical: 30 seconds for one user-month, longer for entity-wide rehydrates or busy entities.
The READY row shows two buttons: a delete (trash) icon and a blue Search this entity button.
Click Search this entity. Forage auto-fills the User filter, populates Since / Until to span the rehydrated months, and runs the search.
Review results and export CSV as needed.

Job states

queued — submitted but waiting to be picked up.
fetching — actively downloading matching files from Azure Blob into the local cache. Progress percentage updates as it works.
ready — cache populated. Forage will include these months in subsequent searches automatically.
failed — something went wrong. The row stays visible with the failure reason. Resubmit after addressing the cause; raise a support ticket if it repeats.

Cache lifetime

Rehydrated data lives in the local cache for 24 hours, then is auto-purged. If an audit takes longer than a day, resubmit the rehydrate — the cold-storage source is permanent, only the local cache expires.

Tips

Scope by entity when you can. A whole-tenant month rehydrate uses significantly more storage bandwidth and cache space than a single-entity rehydrate. Auditor questions are usually entity-specific.
Pre-warm before a big audit. If you know an audit window is coming, rehydrate the months you'll need ahead of time.
Watch the all-jobs list. If multiple operators have rehydrated the same entity recently, the data is already cached — your search will pick it up without a fresh rehydrate.