Backup 3-2-1-1-0: backups must be paired with restore tests
Understand each part of 3-2-1-1-0 and test whether backups are usable when the primary system fails.
Updated: · Vietnam time (UTC+7)
The rule's meaning was checked against Veeam documentation. Review questions are editorial suggestions, not a security certification.
Source record before consolidation
Original title (English translation): Backup 3-2-1-1-0
Source: No.Ransomware.VN · Original date: (the source records only the date)
Original URL: https://no.ransomware.vn/backup-3-2-1-1-0/
The original is retained for comparison. The update history below records changes to sources, scope and assessments.
Read the five numbers correctly
- 3: at least three data copies, including the working copy.
- 2: store on two different types of storage media.
- 1: keep one copy at another location.
- 1: keep an appropriate offline, isolated or immutable copy.
- 0: no unresolved errors in integrity and restoration checks.
A backup's existence does not prove recoverability
CISA recommends maintaining offline, encrypted backups and testing them regularly. In actual operations, a successful backup status is only part of the assessment.
Teams need to know which copy contains the required data, who can access it, where encryption keys are managed and whether the application runs after restoration.
Checklist for a recovery exercise
- Select a critical system and identify the required recovery point.
- Record versions, application dependencies, accounts and required permissions.
- Restore in an isolated environment under an approved procedure.
- Open and check the data in the actual application; add appropriate consistency checks for SQL.
- Measure completion time, missing data and manual steps.
- Record errors, remediation owners and the next test date.
Technical assessment
Separating backup administrator accounts from everyday accounts reduces the chance that one compromised account can affect every copy. Test immutability against actual permissions and retention periods, not just interface labels.
The goal is to know the operational level an organization can restore and how long it takes. Backup rules guide design; recovery capability must be demonstrated through tests.
SQL, NAS and VMs: test at the application level
Copying individual live MDF/LDF files does not replace a consistent SQL backup. Preserve appropriate full/differential/log chains, keys and dependencies; exercise restores and consistency checks on restored databases.
RAID tolerates some hardware failures but is not backup against encryption or accidental deletion. NAS snapshots sharing administrator privileges can be deleted together. Independent copies, separate permissions and retention tests with actual privileges are needed.
For ESXi/Hyper-V, verify application consistency and entire virtual-disk/snapshot/checkpoint chains. VM snapshots do not replace independent copies. Test boot, services and data in isolation.
Measure RPO/RTO and retain copies long enough
RPO expresses time-based tolerable data loss; RTO is the target time to resume operations. Measure infrastructure preparation, key retrieval, restoration and application checks, not only copying.
Retention should cover business needs and environment-specific detection delays. Immutability matters only when compromised accounts cannot shorten retention or delete protected copies; keep keys and recovery privileges separate.
Explain each layer
Five numbers must correspond to five demonstrable controls
Three data copies
One working copy and at least two independent copies. Snapshots on the same storage are not independent if they share administrator access.
Two storage types
Combine platforms/media with separate failure domains, such as local storage and object storage. Avoid shared firmware, accounts and failure points.
One off-site copy
Locate it outside the primary site or production blast radius to protect against fire, theft, sabotage and widespread infrastructure failure.
In-depth design
Separate copies from ransomware's blast radius
Separate administrator privileges
Use separate backup accounts, MFA and secret storage. Domain Admin or production NAS accounts must not be able to delete immutable copies.
Lock retention periods
Set retention long enough to cover ransomware dwell time. Control policy changes and alert on attempts to shorten retention.
Recover in a clean environment
Test restores in isolation, scan for malware, compare checksums and test applications. Return only clean data to production.
Recovery tests
Zero is the most commonly forgotten part
“Backup Successful” confirms task execution, not recoverability. Each test should record RPO, RTO, data scope, checksums, application dependencies, encryption keys, accounts and time to restore service.
- Review logs and address every warning, not only red errors.
- Restore samples weekly; exercise complete-system recovery quarterly or according to criticality.
- Randomly test both recent files and older retained versions.
- Record the owner, results, timing and corrective actions.
Sources
Each source's scope and date are recorded separately when available. A citation does not independently verify every assessment.
Update history
· Consolidated No.Ransomware.VN technical material (original date 12/09/2026), adding SQL MDF/LDF, NAS/RAID, VMs, retention and RPO/RTO. Retained the Ransomware.VN URL and publication date.
· Initial publication with sources and verification limits.
Corrections policy
