Backup Independence Test¶
Test or assessment — instantiates Common-Mode Failure Analysis
Exercises backup paths under a shared dependency outage or simulated common cause to verify whether they are genuinely independent.
An ordinary failover drill asks "does the backup turn on?" A Backup Independence Test asks a harder question: "does the backup turn on when the thing it secretly shares with the primary is gone?" It takes a specific, named independence assumption — the standby runs even if the utility feed dies, the alternate site works even if the identity provider is down — and puts it under live, adversarial conditions by actually removing the suspected common cause and watching whether the redundant path survives without it. The defining move is that a passing failover under normal conditions counts for nothing here; the test is designed to be passed only if the paths are independent with respect to the failure that matters. It converts an independence claim from a belief into an observation.
Example¶
A colocation data center believes its power is triply protected: the utility feed, a bank of UPS batteries, and two diesel generators. On paper, no single loss should darken the racks. The Backup Independence Test does not simply flip to generator on a calm afternoon — that only proves the generator runs. Instead the facilities team schedules a controlled full loss of the utility feed at 2 a.m., staffed and ready to abort, to see whether the whole chain carries the load with the utility genuinely gone.
Within seconds two things surface that a normal drill would never have shown. Both generators are commanded by a single automatic transfer switch — one device, not two — so the "two generators" share a decisive point. And the batteries that are supposed to bridge the gap are sized for a shorter ride-through than the generators actually take to reach full load, because nobody had tested the two together under a cold start. The racks stay up this time only because the operators abort and restore the feed. The output is not "the backup works"; it is a sized, evidenced finding: the redundancy is real for a generator fault but false for a transfer-switch fault, which is exactly the distinction the paper diagram hid.
How it works¶
The test is built backwards from a shared cause, not forwards from a component:
- Name the suspected common cause. Pick the specific shared dependency the independence assumption is betting against — a power feed, a credential store, a network segment, a fuel supply, an operator on shift.
- Remove it for real, or simulate it faithfully. Induce the actual loss (pull the feed, revoke the token, sever the link) rather than a benign toggle. The realism of the removal is what gives the result its evidential weight.
- Observe the redundant path unaided. Watch whether the backup preserves the protected function without the removed dependency — including its activation and recovery steps, which are where shared couplings usually hide.
- Capture the failure, not just the pass. If a path drops, record what shared element took it down; that finding is the test's real product.
The whole design is bounded and reversible: staffed, time-boxed, with a rehearsed abort, so the test challenges the assumption without becoming the outage it is studying.
Tuning parameters¶
- Removal realism — from a tabletop-style flag ("assume the feed is gone") to a genuine hard cut. Higher realism yields stronger evidence but raises operational risk; match it to consequence and reversibility.
- Which shared cause to induce — you can only pull one or a few per test, so this dial decides what the test can prove; aim it at the dependency the independence claim is most quietly resting on.
- Announced vs. unannounced — a scheduled test checks the machinery; a surprise test also checks the human and procedural response, at the cost of goodwill and safety margin.
- Scope — one backup pair versus a whole protected function's paths at once. Wider scope surfaces cross-path coupling but is harder to abort cleanly.
- Abort threshold — how much degradation you tolerate before restoring the removed dependency. Tight thresholds are safe but may stop short of the real failure point.
When it helps, and when it misleads¶
Its strength is singular: it is the only mechanism here that turns an independence assumption into evidence. Maps and analyses can argue that two paths are coupled; only the test proves whether the coupling actually defeats the backup under load. It is the corrective for "backup that has only ever been exercised in fair weather" — much as a generator that has only ever idle-tested can still fail a real load, which is why operators insist on load-bank testing rather than no-load runs.[n1]
Its failure mode is test theater: inducing a condition that does not actually stress the shared cause, so the backup passes for the wrong reason and everyone relaxes. The classic misuse is testing failover with the suspected common dependency still quietly present (switching to the standby while the shared identity provider is up), which proves nothing about the case that matters. The guarding discipline is to write the pass/fail criterion in terms of the removed dependency, and to treat a test that could not have failed as no test at all.
How it implements the components¶
independence_validation_probe— the test is the probe: a live, bounded challenge to whether the backup survives loss of the shared cause.independence_assumption— it takes one explicit assumption as its hypothesis and either falsifies or confirms it against real conditions.redundancy_set— it operates on a named set of backup paths, and its findings sharpen that set into "independent for X, coupled for Y."
It does not first enumerate the shared_dependency_map (that is produced by Credential and Infrastructure Dependency Audit) or the common_failure_mode_map (that is Common-Cause FMEA); and unlike its nearest twin the Tabletop Cascade Exercise — which talks a common cause through and drafts a mitigation_plan — this one physically induces the outage rather than discussing it.
Related¶
- Instantiates: Common-Mode Failure Analysis — this test supplies the evidence that an independence claim is true or false.
- Consumes: Credential and Infrastructure Dependency Audit — its dependency map tells the test which shared cause is worth inducing.
- Sibling mechanisms: Common-Cause FMEA · Correlated Risk Register · Credential and Infrastructure Dependency Audit · Diverse Vendor Review · Fault Tree with Common-Cause Branching · Supply-Chain Dependency Review · Tabletop Cascade Exercise
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Exercises backup paths under a shared dependency outage or simulated common cause to verify whether they are genuinely independent, making its operative form a deliberate probe, variation, simulation, or practiced execution used to generate evidence or readiness.
Independent corroboration: The frozen evidence defines Backup Independence Test as 'Exercises backup paths under a shared dependency outage or simulated common cause to verify whether they are genuinely independent', so its operative form is Experiment, Test & Rehearsal.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Reliability engineering tests redundant paths under a removed common dependency to establish genuine independence.
Related originating lineages:
- Computer Science & Software Engineering — Resilient system design applies the test to identity, regions, and infrastructure dependencies.
- Disaster Management & Risk Reduction — Continuity exercises test whether fallbacks survive the same hazard as the primary.
Review resolution: Engineering design is the agreed primary lineage through reliability and common-mode failure testing. Computing and disaster planning materially apply the test, but the independence principle is a canonical reliability-engineering lineage.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Load-bank testing is the reliability-engineering practice of exercising a standby generator against an artificial full electrical load, because a generator that starts and runs unloaded can still fail to carry real demand. It is the direct analogue of this mechanism: proving the backup works only under the stress it will actually face. ↩