The backup that survives a compromised administrator
"We're active-active" is not an answer to the ransomware question. Here is what is.
The misunderstanding
Asked about its ransomware protection, a technical team very often answers: "we replicate in real time to a second site." The sentence describes protection against site loss. It says nothing about protection against corruption — and it actually worsens that scenario, since propagation becomes instantaneous.
In a large-scale attack, the attacker goes for domain administration rights. Once they hold them, they reach production, replication, monitoring and — the decisive point — the backups.
The decisive criterion
A backup is immutable if it cannot be modified or deleted for a defined period, including by an administrator with full rights. That final clause is the whole subject.
The test is simple: ask your backup administrator to delete a recent backup. If they succeed, it is not immutable — and an attacker who obtains their rights will succeed too.
The three implementations that hold
Object lock on compatible storage, with a compliance-mode retention period, prevents deletion even by the account owner.
Offline tape, physically disconnected, remains the most robust protection and the slowest to restore. It has no equivalent for data whose loss would be existential.
A remote repository with separate authentication, on infrastructure whose administration does not depend on the production directory, combines robustness with an acceptable restoration time.
Isolation, the most frequently missed point
A backup stored on a server joined to the same directory as production, administered with the same accounts, falls with production. Physical distance changes nothing.
Three principles close the gap. Separate accounts: the backup administrator is not the production domain administrator, and their compromise does not follow from the domain's. Independent authentication, ideally a separate directory. A one-way flow: production pushes to backup; backup does not allow itself to be queried or driven from production.
The "zero" everybody forgets
The 3-2-1-1-0 rule ends with a zero: zero errors on restore verification. A "successful" backup report attests that data was written. It does not attest that it is restorable, consistent and usable.
Three levels of verification are expected: daily restoration of a sample, monthly or quarterly restoration of a complete database in an isolated environment with application-level checks, and annual restoration of an entire service end to end with measurement of the actual duration.
DORA Article 12 explicitly requires restoration systems to be periodically tested and backups to be physically and logically separated from the source system. An undocumented restore test does not meet the requirement.