RAID 1 Recovery: One Mirror Is Usually Enough, and Two Commands Destroy Both

RAID 1 is the level where recovery ought to be simple. There is no parity to rebuild, no stripe order to work out, and each disk holds a complete copy of everything. In practice it is also the level where people destroy their own data most casually, because the array still looks alive and the fix looks obvious.

The failure is rarely what loses the data. The next command is.

What mirroring gives you, and the one thing it never did

RAID 1 keeps two or more disks identical. Every write goes to every member, so any single member is a full copy of the whole set. That is the entire mechanism, and it is why the recovery odds are good.

It is also why the protection is narrower than people assume. A deletion is a write. So is an encryption by ransomware, an overwritten file, a corrupted save. Mirroring propagates all of them to both disks at machine speed, faithfully, because that is precisely the job.

RAID 1 protects against a disk dying. It has never protected against anything reaching the data through the filesystem. If your files vanished and the drives are healthy, the array did exactly what it was built to do, and no amount of RAID knowledge will bring them back. That is a file recovery problem on a mirror, not a RAID problem.

The rule that decides how this ends

Before any diagnosis, the Linux RAID wiki gives one instruction, and the parenthesis is the important part:

don't issue any commands that will write to the disks (like mdadm -C, fsck or even mount etc).

Most people read that list and stop at the first two. Mounting is on it. A journalling filesystem replays its journal when mounted, which is a write, performed before you have decided anything. On a degraded array with a member you have not yet identified as good, that write can land in the worst possible place.

The same page rules out the approach almost everyone takes under pressure:

Don't try to fix things in a trial-and-error manner, have someone review the measures you're about to take to get your data back before putting them into practise.

Trial and error works when attempts are free. Here each attempt can be the one that removes the copy you needed.

Three situations, and only one of them is hard

One member has failed and the array still runs. This is the good case and it deserves no drama. You have a complete copy. Copy your data off now, to somewhere else, before doing anything about the failed disk. Replacing it first and rebuilding puts your one surviving copy under a full-disk read at exactly the moment you cannot afford a second failure.

The controller or the machine died and the disks are fine. Nothing has been lost. The data is intact on each member, and the only question is how to reach it, which the metadata version answers below.

The members disagree and you do not know which is current. This is the only genuinely difficult case, and it is a diagnostic problem, not a repair problem. Everything that destroys data lives here.

Two identical-looking lenses, and only one of them is putting anything on the film. Knowing which is which is the whole job.

Why your single disk looks unformatted

The advice you will find everywhere is that you can pull one disk from a mirror and read it like a normal drive. That was true, and the default changed.

The mdadm manual is precise:

The different sub-versions store the superblock at different locations on the device, either at the end (for 1.0), at the start (for 1.1) or 4K from the start (for 1.2).

Read what that implies. With 1.0, the superblock sits at the end, the filesystem begins at offset zero, and a single member does behave like an ordinary disk. With 1.1 and 1.2, the metadata occupies the beginning, so the filesystem starts further in. A tool looking at offset zero finds metadata where it expected a partition table, and reports the disk as unformatted or raw.

1.2 is the modern default. So the most common outcome, on the most common configuration, is a disk that looks blank and is completely intact. People who reach for a formatting prompt at this moment lose everything, and the disk was never damaged. It was offset.

The command that eats arrays

When assembly fails, the internet will suggest recreating the array with the same parameters. The wiki addresses this directly:

Recreating should be considered a last resort, only to be used when everything else fails. People getting this wrong is one of the primary reasons people lose data.

And it explains the trap that makes it so unforgiving:

Using an mdadm with different defaults than the one originally used to create the array will result in the array being completely unaccessible.

The parameters that matter are not only the ones you type. They include the defaults of the mdadm version that built the array years ago, on a distribution you may no longer be running. Recreating with today's defaults writes today's metadata layout over yesterday's, and the mismatch is not recoverable by trying again.

--assemble reuses what is already on the disks. The manual describes it as assembling the components of a previously created array into an active array. That is the safe direction: it reads the existing description rather than replacing it. And when you do assemble, --readonly exists for exactly this moment. The manual states it will start the array read only rather than read-write as normal, with no writes allowed to the array, and no resync, recovery, or reshape started. A rebuild that begins on its own, before you have identified the current member, is the failure mode you are guarding against.

The order that keeps your options open

Power down rather than experiment. A degraded array left running is a rebuild waiting to start.

Image both members before anything else. Not the good one, both. Cloning a disk is a read, so it costs you nothing, and every subsequent mistake becomes reversible. This single step is what separates a bad afternoon from a permanent loss.

Work on the copies. Assemble read-only, mount read-only, recover from images.

Identify the current member before you rebuild, not after. If both disks were online until recently, compare what the metadata says about each. If you cannot tell, that is a reason to stop, not a reason to pick one.

Rebuild last. Once your data is somewhere else entirely, a wrong guess costs nothing.

The short version

RAID 1 is the most recoverable level there is, because each disk is a complete copy and there is nothing to reconstruct. What ruins it is writing before diagnosing, and the Linux RAID wiki puts mount on the list of things that write.

If your disk looks unformatted after you pulled it from the array, check the metadata version before you believe it. With 1.1 and 1.2, the modern defaults, the filesystem does not begin at offset zero and the disk is intact. And treat recreating the array as the last thing you ever try, because the defaults that built it matter as much as the parameters you remember.

Image both disks, assemble read-only, and rebuild only once the data is safe somewhere that is not the array.

The instruction not to issue commands that write to the disks including mount, the warning against trial-and-error repair, the description of recreating as a last resort and the note about differing mdadm defaults are taken from the Linux RAID wiki. The metadata superblock locations for versions 1.0, 1.1 and 1.2, the description of --assemble and the behaviour of --readonly are taken from the mdadm manual page. Both were checked at the time of writing; verify against the 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 data recovery: the full method for RAID 0, 1, 5, 6 and 10 - the wider picture, including the parity levels where a mirror's logic no longer applies.
• RAID recovery software compared - what the tools can and cannot reconstruct once you have clones.