Backup isolation works by keeping at least one usable recovery path outside the event that can destroy or disable the original. The important distinction is not “another copy” but “another copy that the same failure cannot easily take away.”
A laptop and a backup drive in the same lost bag illustrate the problem immediately. The files existed twice, yet one event removed both copies. Digital arrangements can contain less visible versions of the same weakness: different folders controlled by one account, recovery keys available only on the missing device, or several copies that all accept the same destructive change.
This guide develops the isolation pillar of How Digital Backups Fail. Backup coverage asks what must be preserved. Isolation asks what must not fail together. Restore testing checks whether the protected material can actually return to useful work.
The examples are fictional teaching cases, not descriptions of eduKate’s systems. They are intended to help students, families and small teams understand recovery design. Do not delete real data, disable live accounts or change retention locks as a learning experiment. Use authorised sample material and involve a qualified administrator where the system or consequences require one.
The Core Idea: Separate the Failure Path
Start with an event, not a storage product. Suppose the event is the loss of a school laptop. A protected copy on an accessible separate device may help. Now change the event to the accidental deletion of a synchronised folder. The same arrangement may behave differently if deletion propagates between devices. Change the event again to loss of account access, and the recovery route may fail before any file can be retrieved.
These are different failure paths. An arrangement can provide useful protection against one without solving the others. Describe its boundary honestly: “This protects against loss of the working device” is a more meaningful statement than “This is completely safe.”
A failure domain is the set of things one event can affect together. It might be physical, such as a room. It might be administrative, such as an account with permission to delete several copies. It might be operational, such as a shared procedure that overwrites every retained version. The phrase is useful because it directs attention from the number of objects to the relationship among them.
The NCSC’s guidance for on-premises backups recommends examining network access, physical storage and administrative credentials as separate parts of isolation. It also distinguishes backup-management access from the route used to receive backup data. These are specific examples of reducing shared exposure, not a promise that any one control makes recovery infallible. [1]
Five Boundaries Worth Examining
The device boundary
Two folders on one device share that device’s fate. Renaming one folder “backup” does not move it outside a damaged drive, a lost laptop or an unavailable operating system. The folder may still help with some editing mistakes, so its value should not be dismissed. It simply should not be counted as protection against loss of the device itself.
Ask a precise question: without using this device, can an authorised person reach a usable copy? The answer requires both preserved material and a working access route. A separate storage location is insufficient when every instruction needed to reach it exists only on the missing device.
The location boundary
A second device can still share a physical event with the first. Consider a school bag, cupboard or office. If the chosen scenario removes access to that whole location, the recovery plan needs something outside it. “Different device” and “different location” are separate claims.
The appropriate distance and storage arrangement depend on the actual risk and the material’s sensitivity. This guide does not prescribe putting private records in an informal location. The principle is to identify the shared physical exposure and choose an authorised alternative that remains protected and reachable.
The account boundary
Different services or folders may still rely on one account, one recovery email or one unavailable authenticator. In that case, the physical copies can survive while access to all of them fails together. Draw the access chain as carefully as the storage chain.
For example, a family might know that coursework exists in two places but discover that the same locked account controls both. A team might have separate storage accounts but one shared identity system through which every administrator must sign in. These are useful questions to raise with the responsible administrator, not evidence that every shared identity arrangement is automatically unsuitable.
The destructive-permission boundary
Who can overwrite a copy, delete it, shorten its retention or make its recovery key unavailable? A backup arrangement may separate where data are stored without separating who can destroy them. The relevant boundary concerns authority over the preserved state.
Imagine an ordinary user needs to create new work and request recovery but does not need to erase historical copies. Giving that user every destructive permission would connect activities that could be separated. The exact controls are system-specific; the reasoning question is whether routine work needs the power to remove the recovery route.
The historical-version boundary
Isolation can also separate the past from an unwanted change in the present. If every copy immediately becomes the newest state, a mistake can travel everywhere. Retained older versions may preserve a point before that mistake. This is a different kind of separation from moving a drive to another room.
A recent copy and a protected history do complementary work. The recent copy limits loss of new material. The history helps when a problem is discovered after it has already been copied. Neither should silently replace the other in the recovery plan.
Offline, Immutable, Encrypted and Independent Are Not Synonyms
These words often appear together, which makes them easy to confuse. Treat each as a different question about the recovery copy. Combining controls can be useful, but naming several features is not the same as demonstrating a complete recovery path.
Offline: what can currently reach the copy?
An offline copy is disconnected from the live path through which ordinary digital activity reaches it. That can reduce exposure to events travelling through that path. It does not automatically address loss of the storage medium, an unreadable format, poor storage conditions or an unavailable recovery key.
CISA’s ransomware guidance recommends offline, encrypted backups and regular testing. Its reason for offline protection includes the risk that accessible backups can be targeted. The advice supports treating reachability as one important control, while the rest of the recovery plan still needs checking. [2]
Immutable: which changes are prevented, for how long?
Immutability concerns restrictions on changing or deleting a preserved object. Read the actual mode, scope, retention period and exceptions. Do not treat the word as a universal promise covering every account action, access dependency or service failure.
AWS Backup Vault Lock illustrates why the details matter. Its documentation distinguishes governance mode, whose lock can be removed with sufficient permissions, from compliance mode after its grace period. It also warns that retention choices can create persistent storage costs. Review the documented lifecycle and account conditions before making an irreversible configuration choice. [3]
Encrypted: who can read the contents?
Encryption helps protect the contents from unauthorised reading. It does not itself prove that the copy is complete, correctly selected or available when needed. It introduces a protected access dependency: the right key or authorised decryption route must remain usable.
A locked container with a missing key captures the distinction. The contents may be well protected and still unavailable to their legitimate owner. Do not respond by publishing the key or putting it in an ordinary shared inventory. Design an authorised recovery route that preserves both protection and access.
Independent: independent of which failure?
Independence is a relationship, not a product label. Two copies may be independent of a single-device loss yet share a room, identity provider or deletion authority. State the event being considered. “Independent of the lost laptop” is a testable claim. “Independent of everything” is not a useful operating description.
A Small Probability Example: Why Shared Failure Changes the Calculation
The following numbers are invented to illustrate a mathematical assumption. They are not estimates of any storage product, school or organisation. Suppose Copy A has a 10% probability of being unavailable during a defined test situation, and Copy B also has a 10% probability.
If those failures are independent, the probability that both are unavailable is 0.10 × 0.10 = 0.01, or 1%. But independence is doing real work in that sentence. Knowing the two individual probabilities does not automatically justify multiplying them.
Now imagine that both copies are in a bag which is unavailable in 10% of the invented scenarios. If that shared event is the only reason either copy is unavailable, both fail together in the same 10% of scenarios. Adding the second copy did not reduce the probability of losing access through that particular event.
The general relationship is P(A and B) = P(A) × P(B given A). In the independent example, knowing that A failed does not change the probability for B. In the shared-bag example, learning that the bag is missing immediately tells us something decisive about both copies.
The practical lesson is not to invent impressive reliability percentages. It is to inspect the assumption before using the arithmetic. A recovery design needs evidence about shared causes, not a multiplication performed on numbers that were never measured. Mathematical precision cannot repair an unsuitable model.
Worked Case 1: Alicia’s Laptop and Travel Drive
Alicia carries a laptop and an external drive containing a recent copy of her coursework. Against an accidental edit, the drive might provide useful protection. Against loss of the whole bag, it does not provide the physical separation she expected. These two statements can both be true.
She first defines the scenario: the working device and everything travelling with it are unavailable. She then asks which authorised copy remains elsewhere and how she would reach it without the laptop. The answer must include a usable device, account access and the correct coursework version, not merely the name of a storage service.
For a safe exercise, she leaves the original devices untouched and asks a parent to help her follow the legitimate recovery route on another authorised device. She restores sample work into a separate folder, opens it and checks the linked assets. Nothing needs to be deleted or lost to discover a missing step.
The final claim is bounded: the chosen coursework was recovered without the travelling devices. It does not establish resilience against every account failure or prove that every project is covered. A good test narrows uncertainty while preserving the distinction between tested and untested scenarios.
Worked Case 2: A Team With Three Folders and One Administrator
A small publishing team keeps three copies in separately named folders. One administrator account can change or delete all three. The arrangement is convenient, but the folder names do not establish a destructive-permission boundary. A mistaken action through that account may still reach every copy.
The team maps ordinary tasks first. Writers need to edit current material. A recovery operator needs to retrieve historical material. A smaller authorised group may need to change retention or remove old copies under policy. These are different activities. The administrator reviews whether the permissions actually reflect those distinctions.
Adding another account would not settle the question by itself. The accounts might share recovery channels, the same privileged workstation or a common management system. The team therefore traces the routes that matter for the selected scenario rather than assuming that more usernames equal independent control.
The exercise remains a review and an authorised test, not a destructive demonstration. The team does not delete historical copies to prove that deletion is possible. It examines configuration, validates access with harmless sample material and records which boundary remains dependent on specialist assurance.
The useful output is a decision about authority: who can create, read, restore, modify retention and perform destructive actions? Separating these questions makes the recovery design easier to inspect. It also makes an emergency handover more precise because a replacement operator can see which actions they are legitimately allowed to perform.
Worked Case 3: Tricia’s Protected History and Missing Instructions
Tricia has protected historical copies of teaching materials. During a practice exercise, she discovers that the instructions explaining the archive format and the authorised recovery process are stored only inside the unavailable teaching platform. The copies are isolated from one failure, but the operator’s knowledge is not.
She creates an approved recovery instruction record in a location available under the relevant scenario. It identifies the archive, the responsible owner, the required software and the secure access procedure. It does not contain passwords or expose student information. The distinction between instructions and secrets remains explicit.
A second authorised person then attempts a sample recovery using those instructions. This reveals whether the process depends on Tricia’s unrecorded memory. If they cannot identify the correct version or know which destination is safe, the documentation is not yet doing its job.
The repair illustrates a broader lesson: isolating data is not enough when the recovery route still depends on the failed system or one unavailable person. At the same time, making recovery instructions accessible should not make confidential material public. The design must preserve the appropriate boundary in both directions.
Isolation Has to Preserve Legitimate Recovery
It is possible to create a recovery copy that is so difficult to reach that it misses the practical deadline. A location may be secure but inaccessible during the hours when recovery is needed. An approval process may protect sensitive information but depend on one absent person. A transfer route may exist but take longer than the activity can tolerate.
These are design trade-offs, not reasons to remove protection. Test the complete authorised route and identify the first delay that changes the outcome. The appropriate repair might be better instructions, a legitimate alternate approver, a prepared test destination or a different arrangement reviewed by the responsible specialist.
Record the difference between emergency access and everyday access. An emergency route should have defined authority and evidence, not become a convenient way to bypass normal controls. The purpose of planning is to avoid improvising that distinction when people are tired and the deadline is close.
Isolation also needs maintenance. New staff, changed accounts, replacement devices and altered workflows can reconnect paths that were previously separate. Recheck the arrangement after meaningful changes. A diagram approved last year is not proof that today’s permissions and recovery dependencies still match it.
The Isolation Review: A Small Set of Good Questions
For each recovery copy, describe the specific failure you expect it to survive. Then inspect its location, access route, change permissions, history and restoration requirements. A concise record can preserve the reasoning without becoming an unmanageable security manual.
- Scenario: which original resource or route is assumed unavailable?
- Surviving path: which copy and authorised access route remain usable?
- Shared dependencies: what location, account, permission, key or person still connects the paths?
- Evidence: which part was reviewed or tested, what remains uncertain and what change will trigger another review?
Do not store the actual secrets in this record. The record can point to the approved process for obtaining access. Someone who can read a planning document should not automatically gain the authority to restore, erase or disclose the information it describes.
Keep the conclusion conditional. For example: “The sample project was restored without the working laptop; the process still depends on the family’s primary account; account-loss recovery needs separate confirmation.” This is a useful finding because it makes the next unresolved dependency visible.
A Safe Classroom Exercise
Draw a fictional system with a laptop, a local drive, a cloud account and a printed instruction card. Place two sample copies into the diagram. Now introduce one event at a time: the laptop is unavailable, the bag is unavailable, the account is unavailable, or a mistaken edit has been synchronised.
Ask students to identify which resources remain and whether they are sufficient to recover the sample activity. The answer should include assumptions. A cloud copy is useful only if the scenario leaves a legitimate access route. An instruction card is useful only if it describes the correct version and process. The goal is to reason about the connections, not to memorise which object is “safe.”
Next, let students improve the fictional design using the fewest changes they can justify. A good answer may relocate one copy, preserve an earlier version or document an authorised access route. They should explain which event the change addresses and which events it does not.
Progress appears when students stop counting copies and start tracing failure paths. The strongest explanations also protect privacy and legitimate access. “Put everything everywhere” is not a mature answer because uncontrolled duplication can create new problems while leaving the old shared dependency untouched.
Frequently Asked Questions
Are two devices always better than one?
They can protect against some single-device failures, but examine what they share. The same bag, account, synchronisation behaviour or destructive permission may affect both. The meaningful question is which additional failure scenario the second device helps the recovery plan survive.
Does an offline copy need other protection?
Yes. Disconnection addresses reachability through a live digital path. The copy still needs appropriate physical protection, usable contents, suitable history and authorised access. A disconnected but unreadable or misplaced archive does not complete the recovery chain.
Can an immutable copy still be unusable?
Yes. Preventing alteration does not establish that the selected data are complete, clean, compatible or accessible. A protected copy of the wrong state is still the wrong state. Check the product’s precise controls and then test the intended recovery activity.
Should I enable the strongest retention lock immediately?
Do not make an irreversible configuration choice without understanding the service, required retention, costs and authority. Strong restrictions may prevent later correction of an unsuitable setting. Use current official documentation and an authorised technical review rather than treating a label as a universal recommendation.
Does using two providers prove independence?
No. They may still depend on the same credentials, recovery email, device, network or administrator. Different providers can be part of a resilient arrangement, but the full access and failure paths must be examined. Brand diversity is not the same thing as demonstrated independence.
Where should recovery keys be kept?
Use an approved protected key-management and recovery process suitable for the system. The planning record should identify the authorised route without exposing the key. The essential design question is whether legitimate access survives the selected failure without creating unnecessary access for other people.
How can a family test isolation safely?
Use invented sample files and an authorised alternative device or destination while leaving originals and accounts intact. Follow the recovery instructions without relying on the resource assumed unavailable. Record the limits of the exercise. There is no need to delete an account or damage real work to learn where the plan depends on it.
What is the best next step after finding a shared dependency?
Describe the consequence and ask whether the dependency is necessary, replaceable or protected by another control. Choose an authorised change that addresses the identified scenario, then test the recovery route again. Avoid adding complexity whose contribution cannot be explained.
Connections Across eduKate
The reasoning connects to dependency substitution: an alternative helps only if it preserves the required function. It also connects to approval authority: a recovery route needs legitimate decision rights, not merely technical access.
For a mathematical comparison, use Bukit Timah Tutor’s guide to checking. A second check is useful when it can reveal something the first route missed. This is an analogy about independent evidence, not a claim that a Mathematics checking method provides digital security.
Sources and Further Reading
- [1] NCSC: Principles for ransomware-resistant on-premises backups.
- [2] CISA: #StopRansomware Guide.
- [3] AWS Backup documentation: Vault Lock, modes and retention considerations.
The Goal Is a Surviving Recovery Route
Do not stop at “we have another copy.” Ask what event the copy survives, how an authorised person reaches it and whether the restored result can support the work that matters. Isolation succeeds when a specific failure no longer removes every useful route back.
Return to How Digital Backups Fail, check the scope in How Backup Coverage Works, and complete the chain with How Restore Testing Works.