Count the original and the two backup copies correctly
The Netherlands NCSC explains the traditional 3-2-1 structure as original data plus two backup copies, two different media and a copy in another location. Use that as the starting vocabulary. Three folders on one drive are not three independent recovery arrangements, and two copies plus the original should not be described as three additional backups.
Identify the actual dataset before counting. A website can need application data, uploaded files and configuration, while a mailbox recovery may need a different scope. A copy that excludes essential components cannot fill the gap merely because another storage location exists. Record what each copy contains and how it connects to the business service that would need to be restored.
Map shared failure risks across the copies
Copy count alone can hide a common dependency. Several copies may share one administrator, account, storage system, encryption key or deletion path. A local problem, credential compromise or service failure can then affect more than one copy. Our copy-and-failure map helps the owner identify that dependency without declaring every cloud or physical-storage design equivalent.
Record which separation is actually achieved and what remains shared. Different folder names or logical storage labels do not explain resilience by themselves. If a provider describes independent storage or protected retention, ask what that means for access and recovery. Keep unsupported assumptions visible and agree what evidence would establish the required protection for the actual business data.
| Review point | What to record | Question still to answer |
|---|---|---|
| Original data | Business dataset and current operating location. | What must be recovered for the service to work? |
| Backup copies | Contents, location and creation process. | Are essential components included? |
| Media/storage diversity | Actual storage and relevant shared dependencies. | Which failures could affect multiple copies? |
| Offsite location | Location and service dependency outside the primary site. | Does the intended location separation exist? |
| Administrative protection | Who can change, encrypt or delete copies. | Could one compromised account destroy recovery? |
| Restoration | Selected point, environment and tested functions. | What has actually been demonstrated? |
Treat offline and immutable protection as additional properties
Offsite, offline and immutable describe different characteristics. A copy can be in another location while remaining accessible through the same administrative account. Protection against deletion or alteration also needs its actual configuration, scope and owner. The UK NCSC's protected-backup guidance focuses on resistance to destructive actions, rather than assuming cloud or on-premises storage has that property by default.
Ask how significant retention, access or deletion changes are authorized and who notices failures. Do not describe an ordinary remote folder as immutable or an always-connected copy as offline. If a provider offers a protective feature, verify the setting and its limitations in the purchased plan. The business needs an operational explanation of what survives the chosen failure scenario, not a collection of reassuring labels.
Connect the copy plan to recovery objectives and history
The rule does not specify how much recent work the business can lose or how quickly its functions must return. Those recovery objectives need their own decisions. It also does not set a retention period. A business may keep multiple copies while rotating away every recovery point that predates a late-discovered error or unwanted change.
Define the important scenarios and review the history actually available. Separate backup frequency from retained generations, access protection and the restore process. A copy that is technically present may require a provider, an unavailable credential or a data-reconciliation decision before it becomes useful. Record these dependencies and agree the required acceptance rather than translating a copy count into a recovery-time promise.
Test recovery as a business result
Select a representative recovery point and restore into a controlled environment. Verify the data and functions needed by the business, with synthetic transactions or supported test modes where relevant. Keep production credentials and external actions controlled so a recovery exercise does not send real notifications, overwrite live records or trigger fulfillment. Record the selected point and observed result.
A successful job status or file extraction is useful evidence but not the whole acceptance. Check whether configuration, permissions and dependencies were recovered too. Keep excluded data and remaining uncertainty in the report. If the recovery point may contain an unwanted change, address trust and incident questions separately; backup separation does not itself prove that a copy is clean or that confidentiality was preserved.
Assign owners for the copies and the next restore check
Keep a named business owner for recovery requirements and a technical owner for backup operation, access and failure handling. Revisit the plan when data, providers or administrative accounts change. Store the inventory and instructions securely without making one open document the source of every recovery secret. A usable handoff should explain what is protected, what is shared and who can restore it.
CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide with practical Israeli website and digital-infrastructure knowledge. We can discuss scoped backup and restoration work described on this site. We do not guarantee data recovery, ransomware resistance or a particular restoration time from a copy-count rule. Agree the actual dataset, protection, restore scope and evidence of acceptance before work begins.