RAID 10 has a reputation for being the easy one. No parity to reconstruct, no stripe arithmetic, just mirrored pairs: find the surviving half of each pair, copy the files off, done. That reputation comes from the textbook definition of RAID 1+0.
The Linux md driver, which is what most RAID 10 arrays outside of hardware controllers actually run on, does not implement the textbook definition. It implements something broader that happens to include it. If your recovery plan assumes pairs, it may be a plan for an array you do not have.
The name promises pairs, the driver does not require them
The md manual opens the section the way everyone expects. It describes RAID10 as providing "a combination of RAID1 and RAID0, and is sometimes known as RAID1+0", and says that "every datablock is duplicated some number of times, and the resulting collection of datablocks are distributed over multiple drives."
Read that second sentence again, because it is doing the real work. It does not say the drives are grouped into mirrors. It says copies are distributed. The manual then makes the consequence explicit: "It should be noted that the number of devices in a RAID10 array need not be a multiple of the number of replica of each data block; however, there must be at least as many devices as replicas."
A three-disk RAID 10 with two copies of everything is therefore a legal, ordinary array. So is a five-disk one. Neither can be decomposed into pairs, because there are no pairs. The redundancy is real, but it is spread across the set rather than confined to couples, and every recovery instinct built on "find the other half of this mirror" has nothing to attach to.
Three layouts hide behind one level number
When the array is created, two things are chosen that never appear in the level number afterwards: how many replicas of each block exist, and where they go. The manual is direct about this: "When configuring a RAID10 array, it is necessary to specify the number of replicas of each data block that are required (this will usually be 2) and whether their layout should be 'near', 'far' or 'offset'."
The three differ only in placement.
Near puts the copies together. The manual describes them as "laid out consecutively ('as close to each other as possible') across the stripes of the array", and notes that with an even number of devices the copies "will likely lay at the very same offset on the different devices". This is the arrangement that behaves like the textbook, and the manual itself calls it "the 'classic' RAID1+0".
Far puts them apart on purpose, "quite distant ('as far as reasonably possible') from each other". The reason is speed rather than safety: "The advantage of this layout is that MD can easily spread sequential reads over the devices, making them similar to RAID0 in terms of speed." An array built for read throughput is very often a far array, and its second copy sits nowhere near the first.
Offset is the compromise, where "all the copies of a given chunk are striped consecutively ('offset by the stripe length after each other') over the devices". The manual expects it to "give similar read characteristics to 'far' if a suitably large chunk size is used, but without as much seeking for writes".
Nothing about the data differs between the three. Everything about where to look for it does.
Why this decides whether reconstruction produces files or noise
Rebuilding any striped array means answering three questions: which disks, in what order, with what chunk size. RAID 10 adds a fourth that the parity levels do not have, which is where the second copy of each chunk lives. Get that wrong and the reconstruction still completes. It just interleaves blocks from the wrong offsets, and the result is a volume that mounts to nothing, or worse, mounts to a directory tree full of files that open as garbage.
This is the practical reason the layout has to be recovered before the data. It is recorded in the array metadata, which is why reading the metadata off every member, before touching anything, matters more here than at any other level. If the metadata is gone and the layout is unknown, it becomes a small search problem: three layouts, a handful of plausible replica counts and chunk sizes, tested against a copy until a filesystem appears. That search is only safe on images, because each attempt is a write in the wrong direction if you run it on the disks.
What a RAID 10 survives, and why nobody will tell you in advance
The most quoted RAID 10 claim is that it survives one failure per mirror pair, so a four-disk array can lose two disks as long as they are not the same pair. That is true of a classic RAID 1+0, and the md manual pointedly refuses to generalise it.
Where it lists how many devices each level tolerates losing, it gives concrete numbers for the others: "this number is one for RAID levels 4 and 5, two for RAID level 6, and all but one (N-1) for RAID level 1." For level 10 it states only that survivability is "dependent on configuration".
That is the honest answer, and it follows from everything above. With two replicas spread across five devices in a far layout, whether a particular pair of dead disks is recoverable depends on whether any block had both of its copies on exactly those two. Two arrays that report the same level, the same disk count and the same capacity can differ on this. It is decided at creation time and it is not visible in the level number.
The operational consequence is simple: after a second failure at level 10, do not assume you are fine and do not assume you are lost. Both conclusions are guesses.
The order that keeps your options open
Stop writing. A degraded array left in service is a rebuild waiting to be authorised, and at this level you may not know which copy it will treat as the source.
Record the metadata from every member before anything else. Layout, replica count, chunk size, device order and event counts. This is the information that turns recovery into a procedure instead of a search, and it is also the information a hasty recreate destroys.
Image every member, not just the survivors. Imaging is a read. It cannot make things worse, and it converts every later mistake into something you can undo. On an array where the correct layout may take several attempts to confirm, working on images is not caution, it is the only way to get more than one attempt.
Assemble read-only, and confirm you can see a filesystem before you believe the parameters. A reconstruction with the wrong layout does not announce itself. A mountable, browsable filesystem with files that open is the test.
Rebuild last, on hardware you have already proven, once the data exists somewhere that is not this array.
Reading files back once you have images and the right layout
Works on an image or a volume you can already mount. It does not determine the near, far or offset layout for you, and it is not a substitute for imaging the members first.
The short version
RAID 10 on Linux is not the mirrored-pairs array its name suggests. The md manual allows a device count that is not a multiple of the replica count, which means arrays with no pairs to recover one at a time. It offers near, far and offset layouts under the same level number, and only near with an even device count resembles the classic RAID 1+0.
Because the copies can be placed far from each other by design, the layout has to be known before any reconstruction is attempted, or the rebuild will complete and produce nonsense. And because placement is chosen at creation, the manual will not say how many disks a RAID 10 can lose: at this level, survivability is dependent on configuration.
Read the metadata off every member, image all of them, try layouts on the copies, and rebuild only once your files are somewhere else.
The description of RAID10 as a combination of RAID1 and RAID0, the statement that the device count need not be a multiple of the replica count, the definitions of the near, far and offset layouts, the note that near with an even device count is the classic RAID1+0, and the statement that survivability is dependent on configuration for level 10, are all taken from the Linux md(4) manual page, checked at the time of writing. Verify against the kernel and mdadm version you are running. Commercial links carry the rel="sponsored nofollow" attribute; an affiliate commission may apply at no extra cost to you.
Related guides
- RAID 1 recovery: one mirror is usually enough - the mirror logic that near layouts inherit, and the two commands that destroy both copies.
- RAID data recovery: the full method for RAID 0, 1, 5, 6 and 10 - the wider picture across levels, including the parity arithmetic RAID 10 does not use.
- RAID recovery software compared - which tools can search for a layout, and which expect you to already know it.
Recover your deleted files → EaseUS
Free scan · deleted, formatted & lost files · Windows & Mac
