RAID redundancy vs backups

What it means

Availability asks whether you can keep accessing current data. Recovery asks whether you can retrieve a needed state after it has been lost or changed. These are related goals, but evidence for one does not establish the other.

The mirror here maintains the current logical state on two members. A surviving healthy member can provide that state after one disk fails. Ordinary deletion is different: it changes the state being mirrored rather than removing a disk. Maintaining the mirror does not, by itself, retain the deleted version.

Try it

Simulation: start with Event = one-disk-failure and Separate retained backup? = no. Change only Event to logical-deletion, then select Compare with baseline to view the two outcomes and the current explanation. These controls evaluate a synthetic local example; they do not inspect or change your disks or backups.

The baseline result is “Mirror may remain available.” Its explanation is: “With one surviving healthy member, a simplified two-disk mirror may continue serving current data. This is not a backup claim.” Changing the event to deletion makes the current result ask whether an earlier state has a recovery source. Compare with baseline still shows the original one-disk-failure result alongside it; the baseline does not change with Event.

Keep Separate retained backup? = no while changing Event. The two-member layout and the disk-failure branch’s healthy-survivor assumption are fixed model conditions, not additional controls.

Reset restores Event = one-disk-failure and Separate retained backup? = no, removes input errors and clears the comparison. It does not change your independently opened or closed FAQ answers or About this model panel.

How it works

The causal difference is whether the event removes a storage member or changes the data being maintained. In the disk-failure branch, the model assumes the surviving member is healthy and readable. That leaves a source for the current logical state, so access may continue. No earlier version is needed to explain that outcome.

A logical deletion takes a different path: it changes the current state, and the mirror maintains that changed state. Redundancy can therefore function as intended while the earlier version is no longer available through mirroring alone. Having two current copies is not the same as retaining two points in time.

For logical-deletion, setting Separate retained backup? to yes changes the result to “Independent recovery source may exist.” The explanation is: “The mirror propagates logical deletion, but an independently retained backup may preserve an older state.” This adds a possible recovery source, not verified recovery. The retained point could be incomplete, inaccessible, older than you need or already reflect the deletion.

For one-disk-failure, the backup setting does not change the computed availability result. That branch relies only on the assumed surviving member; it does not evaluate a backup restore. An unchanged result there says nothing about whether a real backup would be usable.

Worked example

This is a synthetic baseline, not a production observation.

The computed result is “Mirror may remain available.” The intermediate condition is the model’s assumed surviving healthy, readable member, which may still serve current data. The backup input is no, yet availability may continue: that is the specific benefit illustrated here. It does not demonstrate recovery of deleted data or establish the health of a real array.

What changes when the condition changes

Change only Event to logical-deletion, keeping Separate retained backup? = no. The result becomes “No recovery source established,” with the explanation “Mirroring current data does not undo deletion.” Unlike a disk failure, deletion changes the logical state that the mirror maintains. Both members can therefore reflect the deletion without either disk having failed. The changed result concerns recovery of the file, not a prediction that the array stops serving other data.

In practice

For a system you own or are authorized to inspect, begin with a read-only inventory: identify the actual storage layout, available health evidence and retained recovery points. Establish whether a recovery point predates the unwanted change and remains accessible independently of the failure you are considering. The useful observation is evidence tied to the particular array and recovery source—not merely a “RAID” or “backup” label.

STOP before rebuilding an array, deleting data or restoring over existing data on the strength of this comparison. If the layout, member health, recovery source or destination is uncertain, preserve the current state and obtain platform-specific guidance. This page supplies no operating-system commands or repair procedure.

Any real recovery drill needs a separate authorized plan with an exact source and destination, an isolated test environment where appropriate, expected data and application checks, and a rollback plan before changes begin. A successful isolated drill supports that tested recovery path under its stated conditions; it does not establish that every future failure is covered.

Limits and unknowns

The scene evaluates only two events for a simplified two-disk mirror. It does not inspect a machine, filesystem or backup, and it performs no network request or external change. Other RAID levels, rebuild behavior, corruption and actual backup retention or restoration are outside its scope.

“Mirror may remain available” depends on the assumed healthy surviving member. “Independent recovery source may exist” depends on the supplied backup assertion. Neither establishes the condition of your storage or proves that a restore will succeed. Real recoverability remains unknown without evidence about the recovery point, access and tested procedure.

If the lab reports invalid input, no calculated outcome applies until you correct the value or use Reset. The initial example and its explanation remain readable without JavaScript; interactive controls require JavaScript.

What to carry forward

Match the protection to the event: a mirror can support continuity when a disk fails, while recovering from deletion requires a retained earlier state. For your own system, the useful next step is to identify both the actual failure tolerance and evidence of a usable recovery point—not to treat either one as proof of the other.