Why recovery copies fail during an attack
Organizations discover their recovery copies are dead at the worst possible moment: after the attack, when the copies are the plan. The failure is almost never exotic. Two mechanisms explain nearly all of it.
Mechanism one: a path existed
The copy sat on the network. Behind a firewall, on a separate VLAN, in a different building, but reachable. Modern crews spend days or weeks inside a network before detonating anything, and mapping the recovery estate is step one. If a route exists from production to the copy, they find it. What most vendors sell as "isolated" is a rule in a firewall, and the attacker who owns the network owns the firewall.
Mechanism two: the credentials worked
The recovery system trusted the domain. Or a cloud account. Or a service credential stored where service credentials get stored. Crews harvest admin logins as a matter of routine before striking; the same login that runs your infrastructure deletes your retention policies. "Immutable" storage governed by a software setting is immutable until someone with root disagrees.
Notice what both mechanisms share: the copy failed because it participated in the system it was meant to survive.
The honest question
Not "do we have copies" but "what would have to be true for our copies to die with the network." If the answer involves a route or a credential, you already know how the incident report reads.
The fix is not more software promising isolation. It is a copy held apart physically: no path, no shared trust, immutability enforced by hardware rather than by a setting an attacker can flip. That copy has a name and a five-question audit.