The encryption pass starts on the file server.
It happens at night because that's when nobody is watching the disks. The attacker has shell. They walk through the volumes, encrypting in place, renaming extensions, trimming originals.
The cron-driven backup scripts on the host don't know any of this. They tar up the same paths they always tar up. The bytes are different now — high-entropy, no recognizable header — but the routine is the routine.
The agent reads the first 64 KB. Something is wrong.
Every backup file the agent sees gets the same treatment: Shannon entropy on the head, magic-byte format check, suspicion score. A normal tar.gz sits around 6.3. A normal .sql dump is well under 5. This file is at 7.97 with no recognizable header.
Off-site upload is refused at the gate.
The off-site backup pipeline runs after the suspicion score. Files flagged HIGH or CRITICAL never get uploaded. Whatever attacker workflow assumes the off-site copy will inherit the encrypted state — that's the workflow that just broke.
The last good backup, the one before 02:14, is still encrypted client-side and sitting safely in object storage. The chain isn't broken; the gate did its job.
You walk in to a paged P1, not a quiet disaster.
The incident ledger shows the timeline: when the entropy started climbing, which paths it spread to, when off-site started rejecting uploads. The pre-incident snapshots are intact. Restore is a one-command path, not a six-week recovery.
Most ransomware playbooks fail at the same step: the backups got encrypted too. This is the step we make impossible.