Direct answer
The useful part of 3-2-1-1-0 is not the count of copies; it is the independence and verified recoverability of those copies. Each digit should become a test: copy inventory, media or failure-domain diversity, off-site survivability, one immutable or offline copy, and zero uncorrected recovery errors.
How to frame the decision
Architecture decisions should be evaluated against shared failure domains. Geographic distance alone does not create independence when identities, management tools or deletion privileges are shared.
For this decision, document the protected service, assumed compromise, required recovery point and the maximum acceptable time to a trusted business state. Keep product capability, configured capability and tested capability as three separate fields: they are rarely identical.
What has been observed in practice?
The following field notes are anonymized and dated so that practitioner experience is not confused with current product documentation or a universal benchmark.
Why can 3-2-1 still fail during ransomware?
Three copies can still share one identity, deletion authority or recovery dependency, so copy count is not proof of administrative independence.
- Translate every digit into a pass/fail test and name the actor who could invalidate it.
- Include business-data confirmation in the zero-error test; infrastructure health alone is not recovery.
- Use public business-interruption cases to explain impact, but do not infer unreported backup failures from those cases.
Decision table
The following factors convert the decision into requirements that can be reviewed, tested and retained as evidence.
| Factor | Practical guidance | Evidence to retain |
|---|---|---|
| Three copies | Count production plus two independently managed recovery copies, not replicas that share one deletion path. | An inventory mapping every copy to its administrator and deletion mechanism. |
| One immutable or offline | Choose a control whose retention cannot be shortened by the compromised production role. | A documented destructive test against the protected retention window. |
| Zero errors | Define zero as a completed verification process, not the absence of backup-job alerts. | Restore samples, checksums, application consistency checks and closed exceptions. |
Validation procedure
Run this procedure in a non-production or isolated recovery environment. Define a named owner and time limit before the test begins.
- Draw the actual trust and data flows before changing controls.
- Translate the requirement into a pass/fail test for the 3-2-1-1-0 backup rule, explained as testable controls.
- Capture timestamps, logs, restored-object counts and operator actions for each decision factor.
- Repeat the test with one dependency unavailable so the result reflects a hostile recovery, not a clean demo.
A pass means the recovery outcome and supporting evidence meet the pre-declared requirement. A partial restore, undocumented manual workaround or result that depends on an unavailable production service should be recorded as an exception—not rounded up to a success.
Common failure modes
These conditions can make a compliant-looking design unusable during an actual recovery.
- Two replicas are counted as two independent backups.
- Immutability can be disabled by the same account that operates production.
- A successful job is treated as proof that an application can be recovered.
Failure modes should become tabletop injects and technical tests. If the team has never performed the recovery while one normal dependency is unavailable, the runbook describes a best-case restore rather than a ransomware recovery.
Evidence checklist
Keep this evidence with the recovery plan so that a reviewer can distinguish a documented capability from a reproduced result.
- Record the design decision, owner, exception and next test date.
- A tested requirement exists for: Three copies.
- A tested requirement exists for: One immutable or offline.
- A tested requirement exists for: Zero errors.
- Evidence includes a date, environment, operator and reproducible procedure.
- The exception path identifies who can accept residual risk.
Which sources support the current claims?
Official sources establish current product behavior or the public incident facts. They do not convert the anonymized practitioner observations into vendor guarantees.
- ASKUL: Information Security IncidentOfficial incident update · Official chronology and recovery information; cited only as a business-continuity trigger.
- Asahi: Notice of System Failure Due to CyberattackOfficial incident update · Confirms suspension of order, shipment and call-center operations in Japan.
- Asahi: Business update after delayed annual resultsOfficial incident update · Confirms the cyberattack-related postponement of full-year results; no backup-control inference is made.
Frequently asked questions
These answers state the decision in plain language and preserve the conditions that can change it.
What should be checked first in a 3-2-1-1-0 review?
Start with recoverable days, the presence of a logical or operational air gap, and the last recovery exercise. Those three answers quickly expose retention, privilege and execution gaps that a copy inventory can hide.
Why is 3-2-1 alone not enough for ransomware?
The copies may still share one identity, control plane or deletion path. Ransomware resilience requires one protected path that survives assumed administrative compromise and has been restored successfully.
What does zero mean in 3-2-1-1-0?
Zero should mean no unresolved errors in a declared verification process. The process should include integrity checks, application behavior, elapsed time and business-owner acceptance.