Anatomy of a Ransomware Recovery: Hour by Hour

The pager goes off at 6:40 on a Tuesday morning, and by 7:15 the storage team is looking at encrypted objects and a ransom note with a countdown in it.

What follows is a composite timeline of a cloud ransomware recovery that goes reasonably well, built from incident patterns that keep repeating. It goes well because of decisions the team made months earlier, and that is why the timeline is worth walking through hour by hour.

The team in this story keeps immutable, logically air-gapped backups on Eon, rotates credentials fast, and has rehearsed the restore. Each of those choices pays off at a specific point below.

Hour zero: the alert

The first alert is a spike in write activity against an object storage bucket, followed within minutes by application errors as encrypted data starts breaking things downstream. The on-call engineer’s first good decision is what they don’t do, which is start restoring anything.

Incident command spins up instead, and the operating assumption goes on the whiteboard early: the attacker is still here until proven otherwise.

Hour one: containment and credential rotation

Affected accounts and network segments get isolated, and credential rotation starts with anything that could reach backup storage. The team snapshots the encrypted state of affected systems before touching them, because forensics and the insurer will both want that evidence intact.

This is the hour where an old decision settles the outcome, since backup storage in this environment shares no credentials with production. The attacker’s access, however deep, stops at the vault.

Hours two to four: scoping the blast radius

Scoping is inventory work under pressure: which buckets, which databases, which VMs, and whether anything left the building. Two production databases and one bucket show damage, and the logs suggest exfiltration was attempted but caught by egress controls.

The tempting shortcut here is to restore everything to last night and move on, and it would be the wrong call, because nobody yet knows when the damage started. Last night’s backup could be nine days into the compromise.

Hours four to eight: finding the clean points

This turns out to be the decisive phase. Content analysis across the backup history shows the object storage damage started 36 hours ago, but one of the databases tells a longer story, with row counts collapsing in one table nine days back and a schema change nobody deployed on the same day.

File-level scanning would have missed that entirely, which is why the team’s platform reads database backups at the logical level, and by early afternoon Eon’s clean-point analysis has marked a trustworthy recovery point for every affected dataset, each one chosen on evidence.

Nine days of dwell time also reframes the incident, so the security side widens its investigation while recovery proceeds.

Hours eight to twenty: the staged restore

Recovery order follows the tiering the team wrote last year, with the revenue-critical database first. The restores are scoped tight: the collapsed table and two neighbors come back from the day-nine clean point, and the untouched majority of the database never moves at all.

Search makes the scoping fast, but the data movement itself takes hours, and everyone knew to expect that, because they’d rehearsed on this exact dataset in the spring. The drill time and the real time land within an hour of each other.

Day two: validation and the careful cutover

Applications run against restored data in an isolated environment before anything reconnects, security validates that no foothold rode back in, and the cutover happens tier by tier through the afternoon. The countdown in the ransom note expires unanswered.

Total data loss lands at a few hours of writes in one table, plus a nine-day-old anomaly nobody had noticed, and the postmortem’s biggest finding is about detection lag, since recovery held up.

The three decisions that made the timeline

Nothing in this story required heroics, and that’s the point. The outcome came down to three choices made long before the pager went off: backups the attacker couldn’t reach, tooling that establishes clean points from content, and a team that had rehearsed recently enough to trust its numbers.

Run your own incident against this timeline and see which hours break down, because that gap analysis is free today and very expensive later.

Frequently asked questions

Do you have to take production offline during ransomware recovery?

Rarely all of it, since containment targets affected accounts and segments while unaffected tiers keep running. Full shutdowns happen when scoping is impossible, which is usually a sign the environment lacked segmentation to begin with.

How long does ransomware sit undetected before the attack?

Days to weeks is common, and that dwell time is why the newest backup is often compromised too. Clean recovery points have to be established from backup content, since timestamps only tell you when data was copied, never whether it was already damaged.

Can you restore only part of a backup after ransomware?

Yes, granular restore brings back individual files, records, or tables while leaving healthy data in place, which shrinks both recovery time and risk. Full-environment restores throw away clean recent data and move far more than the incident requires.