Your cold log archive rehydrates in nine hours and a live intrusion case needs eight-month-old sign-in logs — what do you do?

## The two ways a horizon fails There are two distinct failures, and confusing them produces bad decisions. **Absence**: the records were deleted and nothing will bring them back. **Lag**: the records exist but sit in an archive tier that takes hours to make searchable. Lag is recoverable and costs wall-clock time and retrieval fees; absence is terminal. A nine-hour rehydration is lag. It is annoying, not fatal, and it becomes fatal only when someone treats it as a stop condition. ## Immediate moves **Start the restore now, narrow.** Retrieval is priced and rate-limited by volume, and a wide request can exceed the working capacity of the search tier as well as the budget. Ask for the smallest slice that answers the question: one source (sign-in logs), a bounded date range around the period of interest, and where the archive format allows it, a filter on the identifiers you already have. Ordering the whole of last spring because it is easier to type is how a nine-hour restore becomes a two-day one. **Do not serialise.** Nine hours of elapsed time costs nothing if the analyst is working; it costs a day if the analyst is waiting. In parallel: examine current sessions and tokens, the recent hot window, and any source with an independent horizon. Identity providers and SaaS platforms keep their own audit trails on their own retention schedules — often reachable through the platform's console or API when your ingested copy has aged out. **Say what the restore gates.** The right question is not `do we want the data` but `which decision changes when it arrives`. Containment of a live intrusion usually turns on present state — which sessions are active, which credentials work, which hosts are talking — not on the eighth month of history. If nothing today depends on it, the restore is background enrichment and the incident lead should be told exactly that. If something does depend on it, they need the ETA immediately so they can weigh acting on partial information against nine hours of adversary freedom. **Preserve while you are there.** Once the slice is rehydrated, hold it out of the normal lifecycle for the duration of the case. Restoring the same window twice because it re-aged is avoidable waste. ## The design lesson The scenario is a symptom of a split made on volume alone. The better split is made on question order: - **Hot for the full horizon:** low-volume, high-value sources that answer the first questions of any case — authentication and sign-in events, DNS queries, cloud and SaaS control-plane audit records, detection and alert metadata. These are small per record, so a long horizon on them is cheap relative to the bulk. - **Cold, or short:** the verbose bulk — full endpoint process telemetry, proxy records, raw network capture. These dominate the ingest bill and answer depth questions, not scoping questions. The test to apply when designing it: *can I scope an intrusion — which identities, which hosts, roughly when — without restoring anything?* If not, the split is wrong, whatever it costs. Cold storage should buy detail, never the ability to start. ## Two claims to be careful about An untested archive is a retention claim, not a capability. Restores fail on expired credentials, changed schemas, formats no longer parseable by the current pipeline, and quotas nobody has exercised in a year. Prove it periodically with a timed retrieval of a known slice, and record the actual elapsed time — that measured number, not the vendor's, is what you quote to an incident lead. And the nine hours are not free of analyst attention on a one-person team. Someone has to place the request, monitor it, re-scope it if it fails, and integrate the result. Budgeting a restore as zero-effort background work is how a small team loses a day it thought it had.