RAID 1 Calculator
The formula
The 50% efficiency tax buys simplicity
RAID 1 halves your usable capacity, which looks wasteful next to RAID 5's (N−1)/N. In exchange it offers the simplest possible failure mode: every disk is a complete copy, so a failed member can be swapped while the system stays online and reads continue from the survivor at full speed. There is no parity computation, no write penalty and no degraded-mode cliff. For boot volumes, database transaction logs and any two-disk system, mirroring is almost always the right answer precisely because nothing clever is happening.
Read scaling is real, write scaling is not
Controllers can service reads from either mirror, so a two-way mirror can approach double the read IOPS of a single disk. Writes must land on every copy, so write throughput stays at single-disk speed and write IOPS are bounded by the slowest member. This asymmetry matters for read-heavy workloads such as web serving and reporting databases, where mirroring can outperform parity arrays, and matters less for write-heavy workloads where RAID 10 — which stripes across mirrors — is the better choice.
Frequently asked questions
Is RAID a backup?
Can I add a third disk to a RAID 1 mirror?
How long does a RAID 1 rebuild take?
Is RAID 1 better than RAID 5 for two disks?
Do mirrors protect against silent corruption?
Source & methodology
Patterson, Gibson & Katz (1988) RAID taxonomy; rebuild-window risk model per Schroeder & Gibson (2007), "Disk Failures in the Real World".
RAID 1: the number, the method and the caveats
You are here because you need a specific number, and you want to see how it was produced before you rely on it. Searchers land on an RAID 1 page for three reasons — to plan, to compare options, and to check that somebody else’s arithmetic is honest. This tool serves all three, and everything after the calculator explains the model instead of hiding it.
There is a habit that separates people who get useful answers from Networks & Storage numbers: they decide what question the figure answers before they compute it. RAID 1 answers “Usable capacity?” — and nothing else, which is precisely why the result is trustworthy.
The useful way to hold RAID 1 is as a ratio with a story attached: usable = disk size (independent of N); write throughput ≈ single disk; read throughput up to N × single disk says how the parts combine, and the 4.00 TB figure above is simply that sentence written in numbers. Everything that follows unpacks one clause of the sentence at a time.
Nothing below is stock text pasted around a number: the worked example computes usable capacity = 4.00 TB from this tool’s own defaults, and the sensitivity section ranks the inputs that move the result — Capacity per disk first, at ≈10.0 % of the headline for a ten-percent error either way in that input. Work down the page and by the end you could re-derive the result in a spreadsheet from memory.
Every input in RAID 1, and what it does to the answer
One formula, published in full: usable = disk size (independent of N); write throughput ≈ single disk; read throughput up to N × single disk. Anything you can read, you can reproduce in a spreadsheet, and that reproducibility is the whole point of printing it rather than hiding it behind a button.
Number of disks (example value 2) is a plain measured quantity — the unit shown in the label is the unit the formula expects. Quantities scale everything downstream — a one-unit error here is multiplied across the whole result.
Capacity per disk (TB) (example value 4) is a quantity rather than a category — precision here is cheap and worth having. This input feeds the formula directly; a defensible figure here is worth more than false precision anywhere else.
Throughput per disk (MB/s) (example value 250) is a measured number in the unit named by the label; the formula does not convert for you. If you are unsure what belongs in this field, look at the printed steps: the substitution shows exactly how the engine uses it.
Disk MTBF (hours) (example value 1,400,000) is a plain measured quantity — the unit shown in the label is the unit the formula expects. Use the value as of today, not as of the last time you looked — time fields drift silently.
Rebuild time for one disk (hours) (example value 6) is a quantity rather than a category — precision here is cheap and worth having. Use the value as of today, not as of the last time you looked — time fields drift silently.
A fully worked RAID 1 example
Rather than describe the calculation, here it is end to end — every substitution in order, starting from the inputs above. Starting figures: Number of disks, Capacity per disk (TB), Throughput per disk (MB/s), Disk MTBF (hours). Run to the end, the usable capacity resolves to 4.00 TB — 8.00 TB raw · 50.0% efficiency on the bands this tool uses.
- Usable capacity = one disk's worth = 4.00 TB from 8.00 TB raw → efficiency 50.0%.
- Every additional member is a complete copy: 2 disks still present only 4.00 TB of unique data.
- Probability one disk fails during a 6-hour rebuild window ≈ 0.00043%.
- With 1 surviving members, the chance the array is lost during that rebuild ≈ 0.00043%. Mirroring keeps this low because a rebuild is a simple sector copy, not a parity recomputation.
Raw capacity — 8.00 TB. If your inputs change, this is usually the first companion figure to move.
Capacity efficiency — 50.0%. This is the number experienced users quote when the headline alone would mislead.
Fault tolerance — Survives N−1 failures (one disk, in a two-way mirror). Compare it against the main result of 4.00 TB before drawing conclusions.
Sequential throughput (approx.) — 250 MB/s. Compare it against the main result of 4.00 TB before drawing conclusions.
Annual failure rate per disk — 0.63%. If your inputs change, this is usually the first companion figure to move.
Overwrite any input above and every line of this example updates with it — the substitution is live, not a screenshot of somebody else’s numbers.
Scenario table: RAID 1 at ±10 % and ±20 % of the key input
Read this table as the practical error bar on the headline figure. It answers the question people actually have after seeing a single number: how wrong could this be if the main input is off by ten or twenty percent?
| Capacity per disk setting | Usable capacity |
|---|---|
| 80 % of the example value | 3.20 TB |
| 90 % of the example value | 3.60 TB |
| example inputs | 4.00 TB |
| 110 % of the example value | 4.40 TB |
| 120 % of the example value | 4.80 TB |
Across 5 settings of Capacity per disk, the result spans 3.20 TB to 4.80 TB. A decision that only works at one row of this table is a decision waiting for an input to move. Reproduce it in the form above by editing Capacity per disk alone; the substitution steps will follow your figures exactly.
Where RAID 1 is fragile — and where it is not
This list was computed for this specific engine just now: each numeric input was nudged ±10 % while every other field held its example value, and the usable capacity was recalculated from scratch. For RAID 1 the ranking is measured rather than guessed, and it belongs to these defaults: shift the starting point and the order can shift with it.
- Nudge Capacity per disk by ±10 % and RAID 1 lands between 3.60 TB and 4.40 TB (sensitivity ≈10.0 %)
Capacity per disk is the dominant lever here: ten percent either way moves the result by about 10.0 %, from 3.60 TB to 4.40 TB. Measure that input from a document rather than from memory. The rest of the inputs earn only a rounding-error of attention, and that asymmetry is the practical payoff of measuring rather than asserting.
Interpreting the RAID 1 verdict
Nobody acts on a bare figure — they act on a figure with a comparison attached. The verdict attached to the default calculation — “8.00 TB raw · 50.0% efficiency” — is one band on a ladder your own figure may sit somewhere else on. How much of that band is luck? On Capacity per disk alone ten percent either way covers 3.60 TB to 4.40 TB. The practical reading rules: read the band as a starting hypothesis, then test it: change the two dominant inputs by ten percent and see whether the verdict survives. Verdicts that survive stress are the ones worth acting on.
The comparison worth making is not with somebody else’s RAID 1 but with the version of your own situation measured last quarter — same formula, same conventions, different inputs.
How people get RAID 1 wrong
Stopping at the first plausible answer. If the result surprises you, the productive question is which input would have to be wrong for the surprise to disappear — then go check that input.
Stopping at the first plausible answer. If the result surprises you, the productive question is which input would have to be wrong for the surprise to disappear — then go check that input.
One mistake is specific to this engine: assuming every input matters equally. The computation above shows Capacity per disk dominating — a careful figure there beats false precision everywhere else.
The subtlest error is answering the wrong question precisely. Confirm that usable capacity is actually the quantity your decision needs — the arithmetic is flawless either way, which is what makes the mistake invisible.
Before you trust your RAID 1: a short checklist
- Check that every field the formula needs actually arrived from a document, not from recollection.
- Record the date and the inputs alongside the number so future-you knows what was assumed.
- Check Capacity per disk before anything else: it is the measured dominant input, ≈10.0 % of RAID 1 per ten percent.
- State, in one sentence, which convention each rate, unit or period in the form is using.
- Validate inputs against a live measurement, not datasheet peak figures.
- Run the ±10 % stress on the top two levers and check that your conclusion survives both.
Five steps from raw inputs to a figure you can defend
The tool does the arithmetic; the routine below is what makes the arithmetic trustworthy. Five steps, a minute total — and afterwards you will know not just what the number is, but which assumption produced it.
Step 1 — gather before you type. RAID 1 depends on number of disks, capacity per disk (tb), throughput per disk (mb/s), disk mtbf (hours), rebuild time for one disk (hours). Collect them from a source document — a statement, a report, an invoice, a log — rather than from memory, because recalled inputs are the single largest cause of wrong results. The fastest sanity test is to guess the answer first and see how far the calculation disagrees.
Step 2 — start from the case you can defend. Enter pessimistic-but-honest figures first; the optimistic run is a ceiling, not a plan. A conclusion that holds on conservative inputs holds everywhere. The fastest sanity test is to guess the answer first and see how far the calculation disagrees.
Step 3 — play with the inputs on purpose. Ten percent up, ten percent down, one field at a time. Within a few minutes you will know this calculation better than most people who quote its results. If the answer changes your behaviour, it deserves a second run with different assumptions.
Step 4 — compute a corridor, not a point. Three runs — worst, likely, best — turn RAID 1 from a snapshot into a range. Plan against the pessimistic end and treat the optimistic end as the upside story. A figure nobody can reproduce is a figure nobody will act on twice.
Step 5 — schedule the next run. In Technology & Computing the inputs drift quietly. Put a reminder a quarter out, re-enter the same fields, and read the change rather than the level. A figure nobody can reproduce is a figure nobody will act on twice.
From calculation to decision: where RAID 1 earns its keep
Numbers earn their keep in conversations, and RAID 1 is no exception. In Technology & Computing discussions around Networks & Storage, this figure decides whether an option stays on the table: it converts an opinionated debate into an arithmetic one, and arithmetic is the only referee both sides accept. One decimal place more than your data supports is one decimal place of fiction.
Used properly this is a five-minute filter that saves weeks. Compute RAID 1, reject what fails, and only then bring in the expensive analysis for the survivors. A figure nobody can reproduce is a figure nobody will act on twice.
There is a personal-administration use people overlook: periodic self-checking. RAID 1 quietly drifts as life changes — rates move, bodies change, costs compound — and re-running it a few times a year catches drift while correction is still cheap. Most surprises in numbers are surprises about inputs, not about formulas.
The questions that come up most about RAID 1
What affects RAID 1 the most?
RAID 1 is driven above all by Capacity per disk. Perturbing only that field by ten percent either way produced 4.40 TB against the 4.00 TB baseline — a ≈10.0 % response.
What is a typical RAID 1?
There is no honest universal average for RAID 1, but there is a reference point: the defaults on this page produce 4.00 TB (8.00 TB raw · 50.0% efficiency). Replace the inputs with your own and compare — that comparison is the useful meaning of “typical”.
How do I calculate RAID 1 by hand?
Use the stated model — usable = disk size (independent of N); write throughput ≈ single disk; read throughput up to N × single disk — and substitute in the order the tool prints (it starts from Usable capacity = one disk's worth = 4.00 TB from 8.00 TB raw → efficiency 50.0%.). On the example inputs the hand route lands on 4.00 TB, exactly what the calculator shows. A spreadsheet reproduces it in two or three cells; doing it once by hand is what makes the automated answer trustworthy.
What happens to RAID 1 if capacity per disk changes by 10 %?
The engine was re-run with that field moved by ten percent while everything else stayed fixed: the usable capacity goes across 3.60 TB to 4.40 TB, a swing of roughly 10.0 % around the 4.00 TB baseline. That ratio is the practical definition of how much this input matters.
Is the RAID 1 result of 4.00 TB good or bad?
Neither, on its own — the label “8.00 TB raw · 50.0% efficiency” is the band this figure falls in for the example inputs, and your own inputs will place you elsewhere on the same ladder. Judge the number against your history and your alternatives, and remember that a ten-percent error in Capacity per disk alone moves it by ≈10.0 %.
How do I calculate RAID 1 manually?
Write down the inputs, then follow the printed steps in order — usable = disk size (independent of N); write throughput ≈ single disk; read throughput up to N × single disk. A spreadsheet replicates it with two or three cells. The manual route is worth doing once to build intuition; after that the calculator saves time and eliminates transcription slips.
How often should I check RAID 1?
Whenever an input changes by more than a few percent, and otherwise on the rhythm of your decisions — before a purchase, a review, a renewal. RAID 1 is a snapshot, not a subscription; stale snapshots are the most common silent error in Technology & Computing planning.
Is RAID a backup?
No. RAID protects against disk failure, not against deletion, ransomware, controller faults, fire, or a bad firmware flash propagating to every disk at once. The "R" is redundancy, not recovery — you still need independent, off-site copies.
Can I add a third disk to an RAID 1 mirror?
Yes, most controllers support three-way mirroring. Capacity stays the same, but the array survives two simultaneous failures and can serve reads from three devices.
Can this tool see the numbers I type?
It cannot. There is no submission step: the calculation happens in your browser and the result disappears when you close the page. Treat the fields above as a scratchpad rather than a form.
What the labels on this page mean
- Raw capacity
- 8.00 TB on the example inputs — a companion figure printed beside the headline of RAID 1 so that no result is read in isolation.
- Capacity efficiency
- 50.0% in the default RAID 1 calculation — one of the secondary figures an experienced reader checks before trusting the primary number.
- Fault tolerance
- Survives N−1 failures (one disk, in a two-way mirror) for the RAID 1 worked case; it sits next to the main result because it carries context the headline leaves out.
- Usable capacity
- The primary output of this tool: 4.00 TB for the default inputs, computed exactly from usable = disk size (independent of N); write throughput ≈ single disk; read throughput up to N × single disk.
- Worked example
- The step-by-step substitution printed above, so the arithmetic can be re-derived by hand or in a spreadsheet.
- Verdict band
- The interpretation attached to a result (“8.00 TB raw · 50.0% efficiency” on these inputs), which turns a bare number into a position on a scale.
- Sensitivity (±10 %)
- How far the RAID 1 moves when a single input is nudged ten percent either way; the ranked list on this page is computed live from this engine.
Method, sources and what this tool cannot tell you
Everything above runs on one stated formula, applied without hidden coefficients: usable = disk size (independent of N); write throughput ≈ single disk; read throughput up to N × single disk. Source of record: Patterson, Gibson & Katz (1988) RAID taxonomy; rebuild-window risk model per Schroeder & Gibson (2007), "Disk Failures in the Real World". Where a professional version of this calculation differs, it differs in inputs and jurisdiction-specific coefficients, not in the algebra — which is why re-checking your inputs beats hunting for a second calculator.
Nothing here replaces a qualified professional, and nothing here is approximate either — the arithmetic is exact, and the honesty is in the inputs you supply. The promise to the reader is narrow and testable: same inputs, same output, no silent rounding, and no figure presented without the formula that produced it.
What to do with your RAID 1 next
Re-run the calculation with your own figures, stress the two most sensitive inputs by ±10 %, and only then act on the result.
Whoever you are (people who need one trustworthy number before their next decision), the next step is the same: replace the example inputs with your own, note the date, and re-run whenever a figure moves. In Technology & Computing, a dated figure is a trend, and an undated one is a rumour.