The right RAID level depends on your drive count, workload, capacity target, and response to a failed drive. A two-drive production server often starts with RAID 1. RAID 10 deserves a look for busy databases and virtual machines. RAID 6 suits capacity-focused arrays that need to survive two failed drives. RAID 5 makes sense only when its one-drive failure limit and rebuild behavior fit the plan. Use RAID 0 for data you can recreate. Data you need to retain also needs a separate backup.
RAID levels for dedicated servers
This table assumes equal-size drives in a conventional layout. N is the number of active drives, and S is the usable size of one drive. It excludes a hot spare, array metadata, partitions, and filesystem overhead.
| Level | Minimum drives | Approximate usable capacity | Failed drives tolerated | First workload to assess | Main cost |
|---|---|---|---|---|---|
| RAID 0 | 2 | N × S | None | Disposable scratch or cache | One drive failure takes down the array |
| RAID 1 | 2 | S for a two-drive mirror | One of the two | Small production server or boot mirror | Half the raw space is used for the copy |
| RAID 5 | 3 | (N − 1) × S | Any one | Read-heavy storage with an accepted recovery plan | Degraded operation and parity writes |
| RAID 6 | 4 | (N − 2) × S | Any two | Larger capacity-focused storage pool | Two drives’ worth of space for parity |
| RAID 10 | 4 | (N ÷ 2) × S | One per mirror pair; some combinations of additional failures | Busy database or VM storage | Half the raw space is used for mirrors |
For two drive bays, RAID 1 is the straightforward redundant layout. With four bays, the choice often comes down to RAID 5, 6, or 10. Their failure rules differ even when two layouts provide the same usable capacity. These conventional minimums and fault limits match Dell’s PowerEdge RAID specifications.
RAID 10 in this guide means mirrored pairs striped together. Linux MD also supports other RAID 10 layouts, including configurations that do not follow the usual four-drive pair model. Check the exact layout before applying the RAID 10 capacity or failure examples to an existing array.
What striping, mirroring, and parity change
Striping divides data across drives so more than one drive can take part in an operation. RAID 0 uses striping alone. It makes the combined space available, but it keeps no information that can replace a missing member.
Mirroring writes the same data to more than one drive. In a two-drive RAID 1 array, either member can supply the data after the other fails. The price is usable space: two 2 TB drives provide roughly 2 TB before overhead, not 4 TB.
Parity stores information used to reconstruct data from a missing drive. RAID 5 spreads single parity across its drives; RAID 6 spreads double parity. The parity is part of the live array. It is not an older copy you can return to after someone deletes a file. RAID 10 combines mirroring with striping and does not use parity.
These layouts define what happens to the array after particular disk failures. They do not, by themselves, guarantee that the application stays online, that the operating system boots after a restart, or that a damaged file can be recovered.
RAID 0: only for data you can recreate
RAID 0 offers the combined capacity of its drives and no disk fault tolerance. With two equal 2 TB drives, the array has roughly 4 TB available before overhead. If either drive fails, the array can no longer provide the complete striped data.
It can suit a render scratch volume, temporary analytics workspace, or cache whose contents can be regenerated from another system. Write down how to recreate the data and how long that would take before choosing it. A game world, customer upload directory, database, or only copy of a backup is a different kind of storage: losing that volume has a lasting cost.
Striping can improve throughput when the drives and workload permit it. It does not guarantee a fixed twofold speed increase. Interface bandwidth, queue depth, request size, application behavior, and the rest of the server can limit the result.
RAID 1: a simple two-drive mirror
RAID 1 keeps a copy of the same logical data on both members of a two-drive mirror. One member can fail while the surviving member continues to serve the array. That makes it a practical starting point for a dedicated server with two bays or a separate pair of operating-system drives.
The capacity calculation is simple. Two 2 TB drives provide roughly 2 TB of array space before overhead. A replacement disk must then be added and the mirror rebuilt. Until the new copy is complete, there is only one healthy copy in that two-drive array.
If the operating system lives on the mirror, test booting with either member unavailable. A mirrored data partition does not automatically mean both drives have a working EFI System Partition, bootloader, or firmware boot path. Dedicated-server UEFI software RAID recovery procedures show why the boot partitions need separate attention.
RAID 1 copies good writes and bad writes alike. An accidental deletion or damaged database record can appear on both drives, so the mirror remains a poor substitute for a versioned backup.
RAID 5: more capacity, one-drive failure tolerance
RAID 5 stripes data and distributed parity across at least three drives. It uses the equivalent of one drive for redundancy. Four equal 2 TB drives therefore provide roughly 6 TB before overhead. The array can continue after any one member fails, then reconstruct the missing data onto a replacement.
That capacity may appeal to a read-heavy file store. The decision gets harder if the server performs frequent small random writes. Updating data and its parity can add work, and a degraded array must reconstruct missing data as it handles requests. The actual effect depends on the drives, controller or software implementation, cache policy, and workload.
Once one member is gone, RAID 5 has used its whole-drive failure margin. A second full drive failure before recovery is complete exceeds that protection. A read error on a surviving member can also complicate reconstruction of affected data. Neither fact justifies a universal claim that every large RAID 5 array will fail during a rebuild. It does justify monitoring, a tested backup, and a realistic disk-replacement process.
Assess RAID 5 when the extra usable space matters, the workload has been measured, and the team accepts its failure limit. For a write-heavy primary database or an array where a second-drive failure margin is required, compare RAID 10 and RAID 6 before ordering.
RAID 6: two-drive failure tolerance for capacity storage
RAID 6 uses double distributed parity. At least four drives take part, and the array can tolerate any two failed members. Four equal 2 TB drives provide roughly 4 TB before overhead. With six of those drives, the idealized array capacity rises to roughly 8 TB.
The second failure margin matters during replacement and rebuild. If a drive fails, another drive can fail before the array loses its whole-drive fault tolerance. RAID 6 still needs prompt action: two failed members leave no further whole-drive margin. It also uses more space for parity than RAID 5 and may have more write work, especially for small updates.
A larger file or media store is a common reason to assess RAID 6. It is not automatically the right layout for every four-drive server. Four-drive RAID 6 and conventional RAID 10 offer the same idealized capacity, yet they handle write patterns and pairs of drive failures differently. Choose against the actual application and recovery plan.
RAID 10: striped mirrors for busy storage
Conventional RAID 10 makes mirror pairs, then stripes data across those pairs. Four equal 2 TB drives provide roughly 4 TB before overhead. It has no parity calculation, which makes it a useful candidate for databases and VM hosts with frequent random writes. Confirm the choice with application latency and throughput tests on the intended drives. RAID level alone cannot predict performance.
The position of a failed drive matters. For a four-drive array with mirror pairs A/B και C/D:
| Failed drives | What remains |
|---|---|
| A | B still holds the first mirror’s data; C/D remain intact |
| A and C | B and D each keep their mirror’s data; the array can remain accessible |
| A and B | The first mirror pair is gone; the array cannot reconstruct its data |
RAID 10 therefore survives any one member failure, and it can survive some two-drive failures. It does not survive every possible two-drive combination. Dell describes its rule as one failed drive per mirrored set. Linux MD’s alternative RAID 10 layouts require their own placement check. Dell’s RAID level guide and the Linux MD manual document those distinctions.
When one member of a pair fails, a rebuild restores its copy from the surviving data. The time and effect on live traffic depend on drive capacity and health, application load, and rebuild settings. Do not select RAID 10 on the assumption that every mirror rebuild will finish within a particular number of hours.
How much usable space do four 2 TB drives provide?
The advertised drive total is 8 TB of raw capacity. The RAID level determines how much of that total can hold application data:
| Four-drive layout | Idealized usable capacity | Whole-drive failure rule |
|---|---|---|
| RAID 0 | 8 TB | None |
| RAID 5 | 6 TB | Any one drive |
| RAID 6 | 4 TB | Any two drives |
| Conventional RAID 10 | 4 TB | One per mirror pair; position matters for two failures |
For a separate two-drive RAID 1, two 2 TB drives provide about 2 TB, before overhead. That example uses two drives, not four.
These are planning figures in decimal TB. An operating system that reports binary TiB will show a lower number, and partitions, array metadata, filesystems, reserved space, and any hot spare reduce available application capacity further. If you want a dedicated RAID 1 boot pair plus a four-drive data array, count six physical drives and verify that the chassis has six supported bays.
What happens after a drive fails?
A level’s fault limit describes whether its data can still be reconstructed from the remaining members. It is not a service uptime agreement. An application can still stop because of a boot problem, a controller fault, a damaged filesystem, or the time needed to replace hardware.
| Level | After the first drive fails | Next step | Exposure until recovery |
|---|---|---|---|
| RAID 0 | The array loses required data | Restore or recreate the volume | There is no array rebuild from parity or a mirror |
| Two-drive RAID 1 | The surviving member can keep the array available | Replace and rebuild the mirror | Loss of its remaining member exceeds tolerance |
| RAID 5 | Remaining drives reconstruct missing data | Replace the member and complete rebuild | Another full drive failure exceeds tolerance |
| RAID 6 | The array can still reconstruct data | Replace and complete rebuild | One further full drive failure is tolerated after the first; two failed drives use all the margin |
| Conventional RAID 10 | The surviving member of that mirror supplies its data | Restore the failed mirror member | Failure of the surviving member in the same pair loses that pair |
Watch degraded operation and rebuilds
The first job is to notice the failure. A controller warning or mdadm status visible only to someone who never checks it does little good. Confirm that an alert reaches the team responsible for action. Record the failed member’s serial number and bay before removing a drive, then monitor the rebuild until the array returns to its intended healthy state.
A hot spare can allow a supported array to start rebuilding without waiting for a technician to insert a replacement. It does not turn RAID 5 into two-failure protection or replace a backup. The failed physical drive still needs attention. Periodic drive-health and array-consistency checks help find problems before an urgent rebuild, but their behavior and schedule depend on the implementation. Red Hat’s RAID management documentation covers monitoring and recovery in Linux.
There is no honest universal rebuild duration. Disk size and type, existing read errors, rebuild priority, and live traffic all matter. If recovery time is a purchase requirement, ask the provider for a documented test using the proposed hardware and workload.
Keep an independent, restorable backup
RAID handles specified drive failures. It does not supply a clean earlier version of a deleted file, undo a bad deployment, or preserve data if the entire server is lost. Keep versioned backups outside the array and test a restore to a different destination. Set retention and restore time around the application, not the RAID level. Dell explicitly warns that RAID does not replace a backup.
For the wider storage design, including drive media and backup planning, see our dedicated server storage architecture guide.
Choose by workload, drive count, and recovery needs
Use the table as a starting shortlist. Then test the shortlist against your own capacity and recovery requirements.
| Server need | Level to assess first | Check before deciding |
|---|---|---|
| Two bays for a production OS and data | RAID 1 | Enough usable space, boot from either member, off-server restore |
| Four or more drives for a busy database or VM host | RAID 10 | Random-write latency, required capacity, mirror layout |
| Four or more drives for mostly read-heavy files | RAID 5 or 6 | Required failure margin, rebuild impact, backup restore time |
| Larger media or archive pool | RAID 6 | Capacity after two parity equivalents, write behavior, replacement process |
| Temporary data that can be regenerated | RAID 0 | Recovery time and the independent source of the data |
Start with the application, not the RAID number. Work out the minimum usable capacity and expected growth. Count the actual drive bays, then separate sequential transfer needs from small random reads and writes. Check how much latency the application can tolerate while a member is missing and during rebuild. Finally, confirm that a backup can be restored within the time the business needs.
Drive type matters as well. An HDD array, a SATA or SAS SSD array, and an NVMe SSD array can respond differently to the same request pattern. A hardware RAID controller and Linux software RAID can also implement the same level through different data paths. Treat which RAID level και which RAID implementation as two decisions; check what the chosen server and operating system support rather than assuming one implementation always wins.
Six questions to ask before ordering a dedicated server
- Which drives and bays are in the quote? Get the physical count, model, capacity, interface, and number of supported spare bays. A quoted raw total is not the usable RAID capacity.
- Which layouts can this server actually run? Ask whether the array uses a RAID controller or operating-system software, which levels are supported, how it boots, and whether a hot spare is available.
- Who receives degradation and drive-health alerts? Confirm whether the provider, your team, or both monitor the array, and how an alert becomes a replacement request.
- Who owns the rebuild? Establish who identifies the bay, replaces the disk, starts or monitors recovery, and handles a failed controller or an operating-system boot issue.
- Has one-drive boot been tested? For an operating-system mirror, ask whether the server can reboot with either member missing. An intact data mirror alone does not answer that question.
- Where are the backups, and who tests restores? Get the retention, location, access, and expected restore time in writing.
Atal Networks offers bare metal server options και α custom server request path. If you need help sizing a storage layout, send the workload, required usable TB, drive count, read/write pattern, and recovery target. Confirm the available RAID and support details for the specific quoted server before placing an order.
Frequently asked questions
Which RAID level is best for a dedicated server?
There is no single best level. RAID 1 is a practical starting point for a two-drive production server. RAID 10 merits a test for write-heavy storage, and RAID 6 suits capacity pools needing two-drive fault tolerance. RAID 5 can fit a read-heavy array when one-drive tolerance and the recovery plan are acceptable. RAID 0 belongs on data that can be recreated.
Is RAID 5 or RAID 10 better for a database?
Assess RAID 10 first for a database with frequent small writes or strict latency needs, then measure it on the intended hardware. RAID 5 uses less space for redundancy across four or more drives but may face more work on small updates and while degraded. The database’s write pattern, durability settings, capacity target, and backup plan decide.
Is RAID 6 safer than RAID 10 if two drives fail?
For any two whole-drive failures, conventional RAID 6 retains array fault tolerance. Conventional RAID 10 survives two failures only if they occur in different mirror pairs. RAID 10 may suit a different performance need, so the two layouts should be compared against both the workload and the failures the operator intends to tolerate.
Can RAID 10 survive two drive failures?
Yes, in some combinations. A four-drive RAID 10 array with pairs A/B and C/D can survive the loss of A and C. It cannot survive the loss of A and B, because both members of one pair would be gone. Check the actual layout before applying this example to Linux MD or another implementation.
How much space is left with four 2 TB drives?
Before filesystem and other overhead, four equal 2 TB drives provide about 6 TB in RAID 5, 4 TB in RAID 6, and 4 TB in conventional RAID 10. RAID 0 provides about 8 TB but no disk fault tolerance. These figures use decimal TB; a system reporting TiB displays smaller numeric values.
Does RAID protect against ransomware or accidental deletion?
No. RAID keeps an array accessible after the drive failures its level can tolerate. It also writes deletions or damaged data across the live layout. Use separate, versioned backups with access controls suited to the threat and run a restore test. A second live RAID member is not a historical copy.
Does a hot spare replace a backup?
No. A hot spare is an unused drive that a supported, configured array can bring into a rebuild after a member fails. It helps reduce the wait for replacement capacity. It cannot restore a deleted file, repair a bad application write, or recover the whole server after a site incident.
Is hardware RAID faster than software RAID?
Neither is faster in every server. Controller capabilities, cache settings, CPU, drive interface, RAID level, and workload affect the result. Compare the same drive set and request pattern, including latency while degraded and rebuilding. The level determines the data layout; the hardware or software choice determines how that layout is managed.
Can a server boot after one RAID 1 disk fails?
It can if the remaining drive and the server’s boot configuration support it. A mirrored operating-system volume alone is not proof. EFI partitions, bootloader files, firmware entries, and provider boot settings can affect recovery. Test a controlled reboot with each mirror member unavailable before relying on that path.
Choose the layout that meets the whole storage requirement: usable capacity, live workload, known drive-failure behavior, and a recovery process your team can carry out. RAID 1, 6, and 10 each solve different problems; RAID 5 and 0 also have valid, narrower uses. Before the server goes live, make sure a drive failure produces an alert, the replacement path is documented, the boot path works, and an independent backup has been restored successfully.
